According to http://www.cognitus.net/html/howto/pthreadSemiFAQ_5.html (still looking for the real posix spec mentioning it), _POSIX_THREAD_PRIORITY_SCHEDULING should not only be checked for being defined but also > 0. Since OpenBSD switched to kernel threads we temporarly don't provide working thread priority functions, so that #define _POSIX_THREAD_PRIORITY_SCHEDULING is -1. We currently patch ptthreads.c accordingly, see http://www.openbsd.org/cgi-bin/cvsweb/ports/devel/nspr/patches/patch-mozilla_nsprpub_pr_src_pthreads_ptthread_c?rev=1.5

See http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/unistd.h.html : "If a symbolic constant is not defined or is defined with the value -1, the option is not supported for compilation. If it is defined with a value greater than zero, the option shall always be supported when the application is executed. If it is defined with the value zero, the option shall be supported for compilation and might or might not be supported at runtime." "_POSIX_THREAD_PRIORITY_SCHEDULING The implementation supports the Thread Execution Scheduling option. If this symbol is defined in <unistd.h>, it shall be defined to be -1, 0, or 200809L. The value of this symbol reported by sysconf() shall either be -1 or 200809L. "

Another option of course is to replace all occurences of #if defined(_POSIX_THREAD_PRIORITY_SCHEDULING) by #if defined(_POSIX_THREAD_PRIORITY_SCHEDULING) && _POSIX_THREAD_PRIORITY_SCHEDULING > 0

Comment on attachment 624690 [details] [diff] [review] check that _POSIX_THREAD_PRIORITY_SCHEDULING is > 0, #undef it otherwise >+#if defined(_POSIX_THREAD_PRIORITY_SCHEDULING) && !(_POSIX_THREAD_PRIORITY_SCHEDULING > 0) We can write #if defined(_POSIX_THREAD_PRIORITY_SCHEDULING) && (_POSIX_THREAD_PRIORITY_SCHEDULING <= 0) right? If defined(_POSIX_THREAD_PRIORITY_SCHEDULING) is true, then it is safe to compare _POSIX_THREAD_PRIORITY_SCHEDULING for equality to 0. If you can find the description of _POSIX_THREAD_PRIORITY_SCHEDULING in a POSIX or Single Unix Specification page, please let me know. Thanks.

gaston: Ah, I didn't see your comment 2. Thanks.

I looked at how NSPR uses _POSIX_THREAD_PRIORITY_SCHEDULING. It seems that NSPR expects not only the functions exist at compile time, but also the functions work when executed. I saw assertions that the relevant pthread functions return 0, and I saw no handling of sched_get_priority_min() and sched_get_priority_max() failures (returning -1). So, I think that we can replace all occurences of #if defined(_POSIX_THREAD_PRIORITY_SCHEDULING) by simply #if _POSIX_THREAD_PRIORITY_SCHEDULING > 0 This is simpler than your suggestion in comment 3. This replies on that fact that an undefined macro gets the value 0L in a C-preprocessor conditional expression.

Well, your call, but as the symbian case already used the way to #undef the sym that's why we've reused the same. But both ways should work. I'm not 100% sure relying on the fact that an undef macro gets a 0L value is very obvious.. What happens if it's explicitely #undef'ed ? it gets 0L anyway ?

Any news regarding that ? can we move this issue forward ? I've stumbled upon it again when updating our port of nspr to 4.9.2.

I've encountered this problem myself and ended up with a patch almost identical to the attached, but any of these proposed solutions seem straightforward to implement. Is there anything in particular still holding up this bug?

The C99 spec says: "After all replacements due to macro expansion and the defined unary operator have been performed, all remaining identifiers (including those lexically identical to keywords) are replaced with the pp-number 0" (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf 6.10.1 Conditional inclusion, step 4)

Comment on attachment 624690 [details] [diff] [review] check that _POSIX_THREAD_PRIORITY_SCHEDULING is > 0, #undef it otherwise As much as I sympathize with your desire to get this landed, Wan-Teh expressed that he preferred the > 0 solution, so if you can provide that patch I can review and land it for you.