This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Obsolete and Removed POSIX Functions
- From: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: Eric Blake <eblake at redhat dot com>,"newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Wed, 17 Feb 2016 13:00:26 -0600
- Subject: Re: Obsolete and Removed POSIX Functions
- Authentication-results: sourceware.org; auth=none
- References: <56C22272 dot 3090805 at oarcorp dot com> <56C22544 dot 6010204 at cygwin dot com> <56C2290E dot 8070807 at oarcorp dot com> <56C2301D dot 4040405 at cygwin dot com> <20160217165329 dot GH29076 at calimero dot vinschen dot de> <56C4A6BE dot 5070107 at redhat dot com> <20160217170609 dot GJ29076 at calimero dot vinschen dot de> <56C4AD88 dot 7080605 at redhat dot com>
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