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 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


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