mailing list of musl libc
 help / color / mirror / Atom feed
* [musl] Promoting extension functions up from _GNU_SOURCE ?
@ 2021-09-27 23:35 Rich Felker
  2021-09-28  5:20 ` Quentin Rameau
  0 siblings, 1 reply; 4+ messages in thread
From: Rich Felker @ 2021-09-27 23:35 UTC (permalink / raw)
  To: musl

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?

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [musl] Promoting extension functions up from _GNU_SOURCE ?
  2021-09-27 23:35 [musl] Promoting extension functions up from _GNU_SOURCE ? Rich Felker
@ 2021-09-28  5:20 ` Quentin Rameau
  2021-09-28 12:39   ` Rich Felker
  0 siblings, 1 reply; 4+ messages in thread
From: Quentin Rameau @ 2021-09-28  5:20 UTC (permalink / raw)
  Cc: musl

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?

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [musl] Promoting extension functions up from _GNU_SOURCE ?
  2021-09-28  5:20 ` Quentin Rameau
@ 2021-09-28 12:39   ` Rich Felker
  2021-09-28 17:04     ` Quentin Rameau
  0 siblings, 1 reply; 4+ messages in thread
From: Rich Felker @ 2021-09-28 12:39 UTC (permalink / raw)
  To: Quentin Rameau; +Cc: musl

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.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [musl] Promoting extension functions up from _GNU_SOURCE ?
  2021-09-28 12:39   ` Rich Felker
@ 2021-09-28 17:04     ` Quentin Rameau
  0 siblings, 0 replies; 4+ messages in thread
From: Quentin Rameau @ 2021-09-28 17:04 UTC (permalink / raw)
  Cc: musl

> > 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!

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-09-28 17:04 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-27 23:35 [musl] Promoting extension functions up from _GNU_SOURCE ? Rich Felker
2021-09-28  5:20 ` Quentin Rameau
2021-09-28 12:39   ` Rich Felker
2021-09-28 17:04     ` Quentin Rameau

mailing list of musl libc

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.vuxu.org/musl

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 musl musl/ https://inbox.vuxu.org/musl \
		musl@inbox.vuxu.org
	public-inbox-index musl

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.musl


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/musl/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git