[musl] Promoting extension functions up from _GNU_SOURCE ?

[musl] Promoting extension functions up from _GNU_SOURCE ?

[Rich Felker]

In a related discussion on IRC, and in light of merging qsort_r, I
noticed that memmem and likely a large number of other functions that
we share with the BSDs are only exposed under _GNU_SOURCE. This seems
wrong. In some cases that's what glibc is doing too, but that's not a
very good reason to do the same. Some of these, like memmem and
qsort_r, are even approved for the next issue of POSIX.

I think it makes sense to start by making a list of functions that are
presently _GNU_SOURCE that the BSDs also have, and then, as long as
they are useful (as opposed to legacy junk) functions we want to treat
as well-supported functionality, and as long as the names are not
problematic, plan to move most or all to _BSD_SOURCE (default
exposure).

For the ones that are POSIX-future, we could go ahead and move them to
baseline _POSIX_C_SOURCE, or wait a bit. Note that we already have
some POSIX-future functions like dup3 and pipe2 exposed that way. For
ones that are in a reserved namespace (like memmem, which matches the
mem* reservation for string.h) I think it'd be very reasonable to move
them right away. For the others, we should probably look at possible
consequences.

Does this sound reasonable? Any volunteers to make such a list?

Re: [musl] Promoting extension functions up from _GNU_SOURCE ?

[Quentin Rameau]

Hi Rich,

> For the ones that are POSIX-future, we could go ahead and move them to
> baseline _POSIX_C_SOURCE, or wait a bit.

What's baseline? Is that 200809L?

Those POSIX-next functions shouldn't be exposed under 200809L anyway,
but under 202XXXL (whatever is decided at release), should they?

Re: [musl] Promoting extension functions up from _GNU_SOURCE ?

[Rich Felker]

On Tue, Sep 28, 2021 at 07:20:05AM +0200, Quentin Rameau wrote:
> Hi Rich,
> 
> > For the ones that are POSIX-future, we could go ahead and move them to
> > baseline _POSIX_C_SOURCE, or wait a bit.
> 
> What's baseline? Is that 200809L?

Yes.

> Those POSIX-next functions shouldn't be exposed under 200809L anyway,
> but under 202XXXL (whatever is decided at release), should they?

The only officially-supported is "latest". Up til now that's meant
2008 (+TCs) only, but my original intent was always that it be moving
with the standard. We generally don't have different version handling
unless there were interfaces *removed* in the new version (like
gethostby* etc.), which are still exposed under the old version.

If there's a reason this doesn't make sense in the future, it can be
reviewed. But if multiple versions are to be 'supported' in any
nontrivial sense (even complex header logic) there should be
compelling reasons to believe just having the new versions would break
things, not just a box-checking exercise.

Re: [musl] Promoting extension functions up from _GNU_SOURCE ?

[Quentin Rameau]

> > Those POSIX-next functions shouldn't be exposed under 200809L anyway,
> > but under 202XXXL (whatever is decided at release), should they?  
> 
> The only officially-supported is "latest". Up til now that's meant
> 2008 (+TCs) only, but my original intent was always that it be moving
> with the standard. We generally don't have different version handling
> unless there were interfaces *removed* in the new version (like
> gethostby* etc.), which are still exposed under the old version.
> 
> If there's a reason this doesn't make sense in the future, it can be
> reviewed. But if multiple versions are to be 'supported' in any
> nontrivial sense (even complex header logic) there should be
> compelling reasons to believe just having the new versions would break
> things, not just a box-checking exercise.

Allright, thank you for the clarification!