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: Yaakov Selkowitz <yselkowitz at cygwin dot com>, "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Mon, 15 Feb 2016 13:37:50 -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>
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.
Similarly, that page lists some methods that should be removed.
I am assuming it is OK to still support them but what should the
guards be?
Did you see my RFC:
https://sourceware.org/ml/newlib/2016/msg00072.html
There are several examples therein, which can easily be found by
searching for "&& !__"
I looked through there and using bcmp() as an example...
-#if __BSD_VISIBLE
+#if __BSD_VISIBLE || (__POSIX_VISIBLE && !__POSIX2008_VISIBLE)
int _EXFUN(bcmp,(const void *, const void *, size_t));
void _EXFUN(bcopy,(const void *, void *, size_t));
void _EXFUN(bzero,(void *, size_t));
+#endif
Where is __POSIX2008_VISIBLE defined?
If POSIX 2013 is requested, then is bcmp() prototyped or not?
It is removed in 2013 and (I assume) obsolete in 2008.
I don't see the rationale for the ! portion.
And I see some CYGWIN conditions replaced with checks for
POSIX 2008. Is that an equivalent check? fexecve() is a
very simple example and AT_FDCWD has a more complicated
conditional.
ucontext.h methods are removed in Issue 7 so I wonder if
the check around <sys/ucontext.h> is right.
The 2013 question may not be fair because I doubt newlib
has been reviewed at all for that. But that's the change
boundary I am looking at.
--joel