Don't define _POSIX_THREADS unless threads are enabled.

[sunfishcode]

Fixes #355.

[anuraaga]

Is it possible to move all the thread related code into the if block? I think most of these (including timers) are not supported, probably just the clock related ones are. Sorry my issue wasn't clear on that.

For context, the library I found uses _POSIX_READER_WRITER_LOCKS presumably because it doesn't create threads, only uses mutex.

[sbc100]

Also, while looking into it I discovered that a more common say to signal no support is to define these macros to -1. Not defining them at seems like it is acceptable but maybe less explicit. For example here is hurd declaring that it doesn't support stuff: https://codebrowser.dev/glibc/glibc/sysdeps/mach/hurd/bits/posix_opt.h.html#163

The found some documentation in https://pubs.opengroup.org/onlinepubs/000095399/ under unistd.h.

[kateinoigakukun]

While porting libidn, I hit a similar issue that gnulib's getopt.c determines the availability of flockfile based on existence of _POSIX_THREAD_SAFE_FUNCTIONS definition. Since wasi-libc defines it, it tries to use flockfile even though it's unavailable in wasip1 (without -threads). https://github.com/coreutils/gnulib/blob/b86d31ade5e8284df1efe339890b674eedf89bcd/lib/getopt.c#L48

I guessed defining these macros to -1 might be a common way in the definition aspect, but checking the definition existence seems more common in use sites. So I code searched both use styles defined(_POSIX_THREADS) and _POSIX_THREADS == in GitHub, and the former seems more common way.

• https://github.com/search?q=%22defined%28_POSIX_THREADS%29%22&ref=opensearch&type=code
• https://github.com/search?q=%22_POSIX_THREADS+%3D%3D+1%22+OR+%22_POSIX_THREADS+%3D%3D+0%22+OR+%22_POSIX_THREADS+%3D%3D+-1%22&ref=opensearch&type=code

Of course, checking both 1. the definition existence, 2. it's not -1 is the most correct way. But given that most of use-sites use defined style check, and the unistd.h doc allows not defining it to advertise that the feature is unsupported, what do you think about moving those threads consts under if block too not to define them? @sbc100

[sbc100]

what do you think about moving those threads consts under if block too not to define them?

Sorry, which threads consts are you referring to here?

Do you mean moving all the other _POSIX_THREAD_XX macros? If so, then yes that does seem reasonable.

[kateinoigakukun]

@sbc100 Ah, yes. I mean all other _POSIX_THREAD_XXX macros. Then I'll create a PR