_BSD_SOURCE in glibc apparently going away

Create issue
Issue #1754 new
Roland Haas created an issue

I just stumbled accross https://lwn.net/Articles/634207/ which states:

--8<-- Also in 2.20, the _BSD_SOURCE and _SVID_SOURCE feature test macros have been removed. The declarations formerly available under those macros are now under _DEFAULT_SOURCE, but, since it's the default, one need not set it explicitly. Roland's suggestion, though, was that most code would (continue to) want to use _GNU_SOURCE or one of the POSIX-specific macros. (See this article for an introduction to glibc feature test macros). --8<--

We use this in some of our option lists to make M_PI and strdup visible.

Keyword:

Comments (4)

  1. Frank Löffler
    • removed comment

    Replying to [ticket:1754 rhaas]:

    I just stumbled accross https://lwn.net/Articles/634207/ which states:

    --8<-- Also in 2.20, the _BSD_SOURCE and _SVID_SOURCE feature test macros have been removed. The declarations formerly available under those macros are now under _DEFAULT_SOURCE, but, since it's the default, one need not set it explicitly. Roland's suggestion, though, was that most code would (continue to) want to use _GNU_SOURCE or one of the POSIX-specific macros. (See this article for an introduction to glibc feature test macros). --8<--

    Worth mentioning (should be obvious due to the quote, but wasn't for me), that this "Roland" isn't "our" Roland. :)

    So, in order for us to support all glibc versions, should we define BSD_SOURCE _and _DEFAULT_SOURCE?

    Frank

  2. Roland Haas reporter
    • removed comment

    Yes the "Roland" in the quote is not me.

    We'd have to check. It is not clear to me what happens if one defines both say _DEFAULT_SOURCE and _POSIX_SOURCE, it may depend on how exactly things appear in feature.h. We may not have to do anything other than setting _BSD_SOURCE which will work for old glibc and new glibc will give us M_PI independent of whether or not _BSD_SOURCE is set (though maybe __STRICT_ANSI__ may cause issues). The help text spit out by configure when it finds that M_PI is not defined now says to use _XOPEN_SOURCE, since the actual definition of M_PI directly depends on __USE_BSD and __USE_XOPEN though that may be changed to something else of course. I'd say we leave things as they are for now until we actually encounter a system that has issues.

  3. Frank Löffler
    • removed comment

    Just defining _BSD_SOURCE I think will trigger a warning, unless _DEFAULT_SOURCE isn't defined as well. https://lwn.net/Articles/590381/ :

    The first of these patches converts _BSD_SOURCE and _SVID_SOURCE into synonyms for _DEFAULT_SOURCE. The deprecated macros remain effective, but cause compile-time warnings to be generated if they are used (unless _DEFAULT_SOURCE is also defined).

  4. Log in to comment