Opened 8 years ago

Closed 3 years ago

Last modified 3 years ago

#11818 closed bug (no change required)


Reported by: kallisti5 Owned by: nobody
Priority: normal Milestone:
Component: System/ Version: R1/Development
Keywords: posix Cc:
Blocked By: Blocking:
Platform: All


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 (5)

comment:1 by axeld, 6 years ago

Owner: changed from axeld to nobody
Status: newassigned

comment:2 by cocobean, 3 years ago


    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 3 years ago by cocobean (previous) (diff)

comment:3 by pulkomandy, 3 years 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.

comment:4 by waddlesplash, 3 years ago

Resolution: no change required
Status: assignedclosed

comment:5 by nielx, 3 years ago

Milestone: R1

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

Note: See TracTickets for help on using tickets.