Re: POSIX 2008 C Extensions and restrict Keyword

[Craig Howland <howland at LGSInnovations dot com>]

On 07/09/2013 09:50 AM, Joel Sherrill wrote:
> Hi
>
> I was reviewing a standards checker report on RTEMS and noticed
> that there are a couple of areas in newlib that need some attention.
> I am sure there are more than this one case that fall into these
> two categories of issues. But I wanted to get some general guidance
> on how to proceed based on this one case -- strtok() and strtok_r().
>
> http://pubs.opengroup.org/onlinepubs/9699919799/toc.htm
>
> #include <string.h>
>
> char *strtok(char *restrict s1, const char *restrict s2);
>
> [CX]  char *strtok_r(char *restrict s, const char *restrict sep,
>        char **restrict lasts);
>
> (1) From the notes, the restrict keyword was added for alignment
> with ISO/IEC 9899:1999 which is C99.  The current sys/cdefs.h
> defines __restrict which is conditionalized based on the compiler
> and language version. Would it be OK to start sweeping __restrict
> in per POSIX/C99?
I would think that we should want them in there.

Assuming that it is done, however, we should use restrict, not __restrict.  The 
latter apparently dates from 2000 when the keyword was brand new.  Since it is 
now pushing 14 years, I suggest that updating sys/cdefs.h to get rid of the __ 
is in order.  More than that, sys/cdefs.h is looking only at GCC versions.  This 
really would be better as a configure check, as you'd think that any remotely 
recent compiler is pretty likely to accept restrict (whether it acts on it or not).
> (2) strtok_r() is part of the POSIX extensions to the C Library. But
> it is wrapped only in __STRICT_ANSI__ while other methods
> in string.h are wrapped in this:
>
> !defined(__STRICT_ANSI__) || (_XOPEN_SOURCE - 0) >= 500.
>
> Should all the methods marked CX (C Library Extensions) in the
> POSIX standard be in a similar conditional? If so what should the
> test be?
There probably should be, but the exact conditions likely vary based on when 
particular functions were introduced.  The GLIBC test (from RHEL man page) for 
strtok_r() is
_SVID_SOURCE || _BSD_SOURCE || _POSIX_C_SOURCE >= 1 || _XOPEN_SOURCE || 
_POSIX_SOURCE,
so probably the right strtok_r() test for newlib would be either
!defined(__STRICT_ANSI__) || _POSIX_C_SOURCE >= 1
or
!defined(__STRICT_ANSI__) || _POSIX_VISIBLE >= 198808
(198808 is the oldest gate for POSIX_VISIBLE given in sys/cdefs.h). The former 
would be more in keeping with how users are supposed to check, but the latter 
appears to be how someone set up sys/cdefs.h to be used.  I lean towards using 
_POSIX_C_SOURCE.
    CX extensions should not be checked using _XOPEN_SOURCE, as that is the 
gate supposed to be used for XSI extensions (XSI is a superset of CX).  So, for 
example, strdup(), being CX, is not really properly gated with _XOPEN_SOURCE.
> That should be enough to start a large chunk of work based on. :)
     Even more work than what you might have initially thought, given that many 
existing gates appear to be improper.  :(
Craig