Opened 5 years ago

Last modified 4 months ago

#11818 assigned bug

Posix __USE_GNU vs _GNU_SOURCE

Reported by: kallisti5 Owned by: nobody
Priority: normal Milestone: R1
Component: System/libroot.so Version: R1/Development
Keywords: posix Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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 :-)

Change History (3)

comment:1 by axeld, 3 years ago

Owner: changed from axeld to nobody
Status: newassigned

comment:2 by cocobean, 4 months ago

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."

  1. #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 */
    
Last edited 4 months ago by cocobean (previous) (diff)

comment:3 by pulkomandy, 4 months ago

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.

Note: See TracTickets for help on using tickets.