Obsolete and Removed POSIX Functions

[Yaakov Selkowitz]

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.

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

https://sourceware.org/ml/newlib/2016/msg00071.html

> If POSIX 2013 is requested, then is bcmp() prototyped or not?

There is no "POSIX 2013"; just as there is no "POSIX 2004" (2001 + 
technical corrigendum), the 2013 edition is the 2008 standard with 
technical corrigendum applied.

> It is removed in 2013 and (I assume) obsolete in 2008.

It was marked legacy in 2001 and removed in 2008.

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

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.

> ucontext.h methods are removed in Issue 7 so I wonder if
> the check around <sys/ucontext.h> is right.

The mcontext_t and ucontext_t *types* are still required in signal.h, 
which is all <sys/ucontext.h> provides.  But that should probably be 
__XOPEN6_VISIBLE || __POSIX2008_VISIBLE instead.

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

I'm all for catching up our headers to the latest standards.

-- 
Yaakov