Obsolete and Removed POSIX Functions

Corinna Vinschen vinschen@redhat.com
Wed Feb 17 16:53:00 GMT 2016

On Feb 15 14:07, Yaakov Selkowitz wrote:
> On 2016-02-15 13:37, Joel Sherrill wrote:
> >On 2/15/2016 1:21 PM, Yaakov Selkowitz wrote:
> >>On 2016-02-15 13:09, Joel Sherrill wrote:
> >>>I am unsure how methods noted by POSIX as obsolete should
> >>>be guarded.
> >>>
> >>>http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap01.html
> >>>
> >>>For example, asctime() and asctime_r() were marked as obsolescent
> >>>in Issue 7.
> >>
> >>obsolete != removed:
> >>
> >>http://man7.org/linux/man-pages/man3/asctime.3.html
> >
> >Agreed. But an aggressive approach would be to warn users
> >and recommend changes. Obsolete is the first step on the
> >path to removal.
> >
> >If I had working code that used an obsolete methods, I
> >wouldn't read a man page to see that I used a methods which
> >was on the way out. I wouldn't notice this unless I was lucky
> >or writing new code.
> >
> >Just wondering if there is a possibility of an action that
> >is helpful to users.
> Technically it would be possible to mark these
> __attribute__((__deprecated__)) if __POSIX2008_VISIBLE.  I'm not sure if
> that *should* be done or not.

I'm really not sure about that.  How's that handled in BSDs or GLibc?
I think none of them adds the deprecated attribute to functions still
implemented and mentioned in *some* standard.

> There are some cases where __CYGWIN__ and/or __rtems__ are used because that
> feature is only implemented on those system(s) and other cases where they
> are clearly in place of a proper feature test.  The question is if the
> headers really need to reflect the former.

Probably not, unless it's required to guard against contradicting
definitions (e.g., in rtems/Cygwin-only headers).


Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20160217/76133004/attachment.sig>

More information about the Newlib mailing list