Posix __USE_GNU vs _GNU_SOURCE

[kallisti5]

we seem to be all over the map on our GNU posix extension macros...

/Builds/haiku/headers/posix> grep -R __USE_GNU *
regex.h:#ifdef __USE_GNU
regex.h:#ifdef __USE_GNU
regex.h:# ifdef __USE_GNU
regex.h:#ifdef __USE_GNU
regex.h:#ifdef __USE_GNU
regex.h:#ifdef __USE_GNU
regex.h:#ifdef __USE_GNU
signal.h:#ifdef __USE_GNU
/Builds/haiku/headers/posix> grep -R __USE_GNU *^C
/Builds/haiku/headers/posix> grep -R "_GNU_SOURCE" *
stdio.h:#ifdef _GNU_SOURCE
stdio.h:#endif /*_GNU_SOURCE*/
string.h:#ifdef _GNU_SOURCE
string.h:#ifdef _GNU_SOURCE
wchar.h:#ifdef _GNU_SOURCE
wchar.h:#ifdef _GNU_SOURCE

Our libroot tests also reflect the confusion as they were mixed and some broken.

I think _GNU_SOURCE is the correct way to go... not sure however so I'm opening this for someone smarter than me :-)

[cocobean]

Reference:

1. ​https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html

   Macro: _GNU_SOURCE
   
       If you define this macro, everything is included: ISO C89, ISO C99, POSIX.1, POSIX.2, BSD, SVID, X/Open, LFS, and GNU extensions. In the cases where POSIX.1 conflicts with BSD, the POSIX definitions take precedence
   

"We recommend you use _GNU_SOURCE in new programs. If you don’t specify the ‘-ansi’ option to GCC, or other conformance options such as -std=c99, and don’t define any of these macros explicitly, the effect is the same as defining _DEFAULT_SOURCE to 1."

2. #define  _GNU_SOURCE    1 /* for strsignal in GNU's libc */
   #define  __USE_GNU      1 /* exact same thing as above   */
   #define  __EXTENSIONS__ 1 /* and another way to call for it */
   

[pulkomandy]

The way it work in glibc is that the user defines _GNU_SOURCE, and features.h defines __USE_GNU and other __USE_* stuff.

Our public features.h works differently, as I don't think the internal __USE_* defines are very useful and they are confusing to track. So when taking headers from glibc and making them public, we have to be careful about this.

I would leave these as is for now unless there are problems compiling things because of this? The BSD extensions that we have in libbsd are quite useful, but the things glibc adds or goes against POSIX for, I'm not so sure.

[nielx]

Remove milestone for tickets with status = closed and resolution != fixed

[bipolar]

Not sure if I should open a new/different ticket, maybe the following is enough to re-open this one? (considering the "I would leave these as is for now unless there are problems compiling things because of this?" on an earlier comment here)...

I had some problems compiling ​TraX, in part due to __USE_GNU vs apparently, some issues with Haiku's features.h

Link to the discussion there: ​https://github.com/HaikuArchives/TraX/pull/4#pullrequestreview-1625900739

Hoping a real dev either fixes this before beta5, or someone just merges my sub-optimal TraX fixes in the meantime :-)

---

Edit: Just for future reference... hrev57485 (and the follow up fixes on hrev57497) fixed TraX's issue mentioned above.