pthread functions hidden under _GNU_SOURCE

[brad0]

I was working on a patch for LLVM/Clang to add support for setting POSIX thread names. As I've done for gazillions of other projects in the same manner.

I was searching around and noticed this commit for Haiku adding the POSIX threads functions most other OS's have for setting thread names.

​https://github.com/haiku/haiku/commit/44cceee67e056d8e34cb017d5f5c07b9fac874c0

I made the miniminal changes to LLVM/Clang to use said API and thought things were good, but then noticed CMake was not detecting the functions that looked to be there.

Digging further I noticed headers/compatibility/gnu/pthread.h hides the functions by default, defeating the purpose of adding the functions. None of the other OS's, FreeBSD/NetBSD/OpenBSD/DragonFly BSD, Solaris, Linux, etc. hide the functions like Haiku does.

[waddlesplash]

This is deliberate. We don't want to define anything past the POSIX specification in default headers if a strict mode is enabled.

This file is in the default include path, and while it doesn't include "features.h" directly, it looks as though it is included indirectly through the main pthread.h's includes (unless I've missed something). In features.h, we gate all non-POSIX functions (in POSIX header names anyway) behind _DEFAULT_SOURCE; which we disable if __STRICT_ANSI__ is defined.

By default, GCC and Clang define this in -std=c... mode, while they don't define it in -std=gnu... mode. If you want these and other non-POSIX methods, then probably the build systems in question should be adjusted to permit the headers to define them (or just define _BSD_SOURCE, or undefine __STRICT_ANSI__ before including something that includes features.h and then pthreads in the appropriate files.)

And it isn't true that no other OS does this; FreeBSD for example puts them behind __BSD_VISIBLE, as you can see in their include/pthread.h. It appears (in their cdefs.h) that they don't define __BSD_VISIBLE if various standards-mode definitions are set, though admittedly __STRICT_ANSI__ doesn't seem to be one of them.

Unless you see something I've missed, I think this ticket should be closed as invalid, and upstream patched to not define a strict standards-mode when it doesn't want that.

(Either way, thanks for working on adding more Haiku support to upstream projects!)

[brad0]

Replying to waddlesplash:

This is deliberate. We don't want to define anything past the POSIX specification in default headers if a strict mode is enabled.

But in this scenario a strict mode is not enabled. e.g. _POSIX_C_SOURCE. Yes, this has been a source of problems with a tiny few projects.

This is building code like cc -c foo.c -o foo.o. Without any other flags.

This file is in the default include path, and while it doesn't include "features.h" directly, it looks as though it is included indirectly through the main pthread.h's includes (unless I've missed something). In features.h, we gate all non-POSIX functions (in POSIX header names anyway) behind _DEFAULT_SOURCE; which we disable if __STRICT_ANSI__ is defined.

By default, GCC and Clang define this in -std=c... mode, while they don't define it in -std=gnu... mode. If you want these and other non-POSIX methods, then probably the build systems in question should be adjusted to permit the headers to define them (or just define _BSD_SOURCE, or undefine __STRICT_ANSI__ before including something that includes features.h and then pthreads in the appropriate files.)

And it isn't true that no other OS does this; FreeBSD for example puts them behind __BSD_VISIBLE, as you can see in their include/pthread.h. It appears (in their cdefs.h) that they don't define __BSD_VISIBLE if various standards-mode definitions are set, though admittedly __STRICT_ANSI__ doesn't seem to be one of them.

Yes, but building without any special flags as is the case here the functions are exposed and that is the case for all of the OS's I mentioned including FreeBSD. The behavior between the other OS's and Haiku is not the same.

Unless you see something I've missed, I think this ticket should be closed as invalid, and upstream patched to not define a strict standards-mode when it doesn't want that.

(Either way, thanks for working on adding more Haiku support to upstream projects!)

[waddlesplash]

Ah, it appears the file uses _GNU_SOURCE guards and not _DEFAULT_SOURCE; that looks like an oversight, indeed. So there is a bug we should fix here.

I'll fix it next week if nobody beats me to it.

[korli]

This doesn't match what I see on Ubuntu:

echo -e "#include <pthread.h>" | gcc -E -  | grep pthread_setname_np
echo -e "#define _GNU_SOURCE\n#include <pthread.h>" | gcc -E -  | grep pthread_setname_np
extern int pthread_setname_np (pthread_t __target_thread, const char *__name)

without flags pthread_setname_np isn't found.

[waddlesplash]

​https://review.haiku-os.org/c/haiku/+/8330

[waddlesplash]

Fixed in hrev58152 +beta5.