This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Obsolete and Removed POSIX Functions



On February 17, 2016 11:27:36 AM CST, Eric Blake <eblake@redhat.com> wrote:
>On 02/17/2016 10:06 AM, Corinna Vinschen wrote:
>
>> 
>> Ok, so there's an example for a dangerous function which is marked
>> obsolete.  This may also make sense for mktemp.  But what about
>> not so dangerous deprecated functions?
>
>I guess it's on a case-by-case basis what we want to do. Depending on
>the name of the function, there are some things that we can leave
>declared without polluting the namespace, even if the function is no
>longer required by newer standards (for example, anything named str* in
><string.h> is fair game to include in the header, regardless of whether
>a standard specifies it); I also think that unconditionally marking
>something as deprecated if newer standards no longer provide it is
>doing
>a service for users.  On the other hand, only exposing the deprecation
>for newer standards (where the namespace pollution is not an issue),
>while letting the function be silently used in older standards, may be
>nicest to people that still intentionally try to target older
>standards.

This matches a private discussion I had with some folks locally. If I build explicitly against an older version with it, let me and follow those rules. If against a newer one and something is removed that I used, the headers could either not provide a prototype and I might get a warning for that or we can provide a prototype and give a message.

FWIW the Open Group FACE Consortium profiles were initially based on POSIX 2001. They were bumped to 2008 and currently include a couple of methods deprecated in 2013. Since these are profiles designed for avionics systems, it was suggested we may keep deprecated and obsolete methods for long term OS API stability for applications. These profiles left out unsafe methods completely.

I am pretty sure most POSIX implementations want to do similar.

>But most functions that are marked obsolescent in POSIX are because
>they
>are unsafe.

Giving advice on unsafe seems reasonable and beneficial.  

I am not so sure on the more general case. I can see a case where you want access to old methods. The Go implementation in GCC uses ucontext which was obsolete when they used it. I don't think there is an alternative for that capability.


--joel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]