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

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

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>

> And FWIW RTEMS supports sysconf() but doesn't have
> a lot of cases in its implementation.  What sysconf value
> covers this one?
Cf. above.

However, people are using the defines to detect the ability of a feature
to "potentially present", while sysconf covers run-time detection.

=> 2 different problems.

Ralf