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. HTH, John.