This is the mail archive of the 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: POSIX 2008 C Extensions and restrict Keyword

On 07/09/2013 09:50 AM, Joel Sherrill wrote:

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

#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
!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. :(

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