Re: [rtems] Tweaks to sys/features.h

[Ralf Corsepius <ralf dot corsepius at rtems dot org>]

On Thu, 2008-11-20 at 13:17 -0600, Joel Sherrill wrote:
> Ralf Corsepius wrote:
> > On Thu, 2008-11-20 at 12:32 -0600, Joel Sherrill wrote:
> >   
> >> Howland Craig D (Craig) wrote:
> >>     
> >>> Wouldn't it be better to define _POSIX_SHARED_MEMORY_OBJECTS with value
> >>> -1 than to have it not defined?  That way it is known at compile time
> >>> that there is no support, rather than needing to wait for runtime for a
> >>> sysconf() call.
> >>>       
> > Likely, but it's what others do in newlib, too.
> >   
> >   
> >> If that's what people are expecting to test for then yes.
> >>     
> >
> > >From SUSv3
> > <cite>
> > The following symbolic constants, if defined in <unistd.h>, shall have a
> > value of -1, 0, or greater, unless otherwise specified below. If these
> > are undefined, the fpathconf(), pathconf(), or sysconf() functions can
> > be used to determine whether the option is provided for a particular
> > invocation of the application.
> >
> > If a symbolic constant is defined with the value -1, the option is not
> > supported. Headers, data types, and function interfaces required only
> > for the option need not be supplied. An application that attempts to use
> > anything associated only with the option is considered to be requiring
> > an extension.
> >
> > If a symbolic constant is defined with a value greater than zero, the
> > option shall always be supported when the application is executed. All
> > headers, data types, and functions shall be present and shall operate as
> > specified.
> >
> > If a symbolic constant is defined with the value zero, all headers, data
> > types, and functions shall be present. The application can check at
> > runtime to see whether the option is supported by calling fpathconf(),
> > pathconf(), or sysconf() with the indicated name parameter.
> > </cite>
> >   
> 
> Interesting, then in sysconf(), having something like this
> for each _SC_XXX constant would be appropriate:
> 
> #if defined(_POSIX_SHARED_MEMORY_OBJECTS)
>     case _SC_SHARED_MEMORY_OBJECTS:
>       return _POSIX_SHARED_MEMORY_OBJECTS;
> #endif

Exactly this is what people are doing (The case this issue surfaced in
RTEMS had been ACE/TAO which applies such kind of code snippets in
autoconf checks).

Provided the issue Howard pointed out, I feel, a strictly SUSv3
conforming implementation would have to use

#if defined(_POSIX_SHARED_MEMORY_OBJECTS) \
  && !(_POSIX_SHARED_MEMORY_OBJECTS < 0)
...
#endif

Nevertheless, SUSv3 says (first sentence from SUSv3 above) 
"The following symbolic constants, if defined in <unistd.h>, ..."

I read this as "allowing the constants not to be present", which would
mean newlib's practice of "not defining" a #define to be permitted.

Ralf