Boost logo

Boost :

From: John Maddock (john_at_[hidden])
Date: 2005-04-05 04:54:24

>> Also, if _POSIX_THREAD_SAFE_FUNCTIONS == 0, I thought that meant *not*
>> supported (in which case sysconf() would return -1) ? Does the test have
>> to be >= not just > ?
>> I'd have written it:
>> # if defined(_SC_THREAD_SAFE_FUNCTIONS)
>> if ( ::sysconf( _SC_THREAD_SAFE_FUNCTIONS ) > 0 )
>> { return ::readdir_r( dirp, entry, result ); }
>> # endif
>> But I didn't realise this wasn't good enough :-|
> This is the first time I've ever used the POSIX config mechanisms, so I
> may have it wrong. I'll check... Hum... I find the POSIX docs for
> sysconf() pretty impeneratable regarding the return value. I can see why I
> took >=0 to be needed, but I could also read it in a way that >0 would be
> OK.
> Any POSIX experts out there?

Not really, but here's my understanding of how things work from when I last
looked at this for the config system:

For the current POSIX standard (see Base definitions, <unistd.h>):

If _POSIX_FEATURE is defined as < 0 then the feature is never available on
that platform.

If _POSIX_FEATURE is defined as > 0 then the feature is always available on
that platform.

If _POSIX_FEATURE is defined as 0 then: "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."

I've no idea about previous versions of the standard, except that it seems
to be common place to define these feature test macros with no value, so I'm
guessing we should treat these as the same as a value of zero.

There are also some platforms that don't define a particular feature test
macro, but none the less support at least some of the option.

Note that if you want to follow the std strictly, then we can't avoid calls
to fpathconf( ), pathconf( ), or sysconf( ) in every case, although can
avoid it in many cases.



Boost list run by bdawes at, gregod at, cpdaniel at, john at