[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220420234933.GB10621@brightrain.aerifal.cx>
Date: Wed, 20 Apr 2022 19:49:35 -0400
From: Rich Felker <dalias@...c.org>
To: libc-coord@...ts.openwall.com
Subject: Re: Macro-based advertisement of libc extensions, cont'd
On Tue, Apr 19, 2022 at 12:26:49PM -0400, Rich Felker wrote:
> Context is picking back up the proposal from 2020:
>
> https://www.openwall.com/lists/libc-coord/2020/04/22/1
> Message-ID: <20200422173825.GA8375@...ghtrain.aerifal.cx>
>
> On the basis of a user frustrated at not having a configure-probe-free
> way to look for extensions (for header-only library use), I started
> looking at this again, actually digging into the scope of what needs
> to be covered. I have a partial list of the interfaces from musl I
> would want to advertise the presence of (which I'll post in a
> follow-up when I flesh it out a bit more), and some general thoughts
> from sorting through them:
Here's a draft list of available macros we could populate the registry
from. I think the first part here should be mostly or entirely
non-controversial since it's modeled on sorting through extensions
musl adopted on the basis of them being widely cross-implementation
already:
crypt.h:
_EXT_CRYPT_R
dirent.h:
_EXT_GETDENTS
_EXT_VERSIONSORT
dlfcn.h:
_EXT_DLADDR
_EXT_DLINFO
glob.h:
[None - there are extension fields to the structure for
implementations with GLOB_ALTDIRFUNC, but the existence of that macro
can reasonably be assumed to imply their presence. I don't see value
in separate macros for it.]
grp.h:
_EXT_GETGROUPLIST
_EXT_SETGROUPS
_EXT_INITGROUPS
_EXT_FGETGRENT
_EXT_PUTGRENT
math.h:
_EXT_J0F
_EXT_J1F
_EXT_JNF
_EXT_J0L
_EXT_J1L
_EXT_JNL
_EXT_Y0F
_EXT_Y1F
_EXT_YNF
_EXT_Y0L
_EXT_Y1L
_EXT_YNL
_EXT_LGAMMA_R
_EXT_LGAMMAF_R
_EXT_LGAMMAL_R
_EXT_SINCOS
_EXT_SINCOSF
_EXT_SINCOSL
_EXT_EXP10
_EXT_EXP10F
_EXT_EXP10L
_EXT_POW10
_EXT_POW10F
_EXT_POW10L
netdb.h:
_EXT_GETHOSTBYNAME_R
_EXT_GETHOSTBYNAME2
_EXT_GETHOSTBYNAME2_R
_EXT_GETHOSTBYADDR_R
_EXT_GETSERVBYPORT_R
_EXT_GETSERVBYNAME_R
poll.h:
_EXT_PPOLL
pwd.h:
_EXT_FGETPWENT
_EXT_PUTPWENT
search.h:
_EXT_HCREATE_R
_EXT_HDESTROY_R
_EXT_HSEARCH_R
_EXT_TDESTROY
signal.h:
_EXT_SIGISEMPTYSET
_EXT_SIGORSET
_EXT_SIGANDSET
spawn.h:
_EXT_POSIX_SPAWN_FILE_ACTIONS_ADDCHDIR_NP
_EXT_POSIX_SPAWN_FILE_ACTIONS_ADDFCHDIR_NP
stdio.h:
_EXT_*_UNLOCKED
_EXT_FGETLN
_EXT_ASPRINTF
_EXT_VASPRINTF
_EXT_FOPENCOOKIE
stdlib.h:
_EXT_MKTEMP
_EXT_MKSTEMPS
_EXT_MKOSTEMP (***)
_EXT_MKOSTEMPS
_EXT_REALLOCARRAY
_EXT_QSORT_R (***)
_EXT_PTSNAME_R
_EXT_SECURE_GETENV
_EXT_STRTOF_L
_EXT_STRTOD_L
_EXT_STRTOLD_L
string.h:
_EXT_STRSEP
_EXT_STRLCAT
_EXT_STRLCPY
_EXT_EXPLICIT_BZERO
_EXT_STRVERSCMP
_EXT_STRCHRNUL
_EXT_STRCASESTR
_EXT_MEMMEM
_EXT_MEMRCHR
_EXT_MEMPCPY
termios.h:
_EXT_CFMAKERAW
_EXT_CFSETSPEED
time.h:
_EXT_TM_GMTOFF
_EXT_TM_ZONE
_EXT_TIMEGM
unistd.h:
_EXT_VFORK
_EXT_CHROOT
_EXT_SETHOSTNAME
_EXT_SETDOMAINNAME
_EXT_GETDOMAINNAME
_EXT_SETGROUPS
_EXT_GETPASS
_EXT_DAEMON
_EXT_SETUSERSHELL
_EXT_ENDUSERSHELL
_EXT_GETUSERSHELL
_EXT_ACCT
_EXT_SYSCALL
_EXT_EXECVPE
_EXT_ISSETUGID
_EXT_GETENTROPY (***)
_EXT_OPTRESET
_EXT_SETRESUID
_EXT_SETRESGID
_EXT_GETRESUID
_EXT_GETRESGID
_EXT_SYNCFS
_EXT_EACCESS
_EXT_COPY_FILE_RANGE
_EXT_GETTID
_EXT_PIPE2 (***)
_EXT_DUP3 (***)
wchar.h:
_EXT_*_UNLOCKED
_EXT_WSCFTIME_L
sys/socket.h:
_EXT_ACCEPT4 (***)
_EXT_SENDMMSG
_EXT_RECVMMSG
sys/uio.h:
_EXT_PREADV
_EXT_PREADV2
_EXT_PWRITEV
_EXT_PWRITEV2
sys/wait.h:
_EXT_WAIT4
Those marked with (***) are POSIX-future, but should still be
advertised as extensions so that their availability can be deduced
before there's a new _POSIX_VERSION.
There are probably a good deal more _l "xlocale" functions that are
widely supported but that musl does not have; these can be added to
the above too.
I've also looked at the following but I have questions about them,
such as not being necessarily convinced they're sufficiently
equivalent (in signatures or semantics) across platforms. They need
investigation:
endian.h:
[I think nothing is needed here because the conversion 'functions' are
macros themselves on implementations I'm aware of. If that's not
universally the case, or if the future standard won't require them to
exist as macros, macros advertising these these could be added.]
getopt.h:
_EXT_GETOPT_LONG
_EXT_GETOPT_LONG_ONLY
[This header is nonstandard to begin with but I'm not sure all
historical versions had getopt_long so I think the macros are
appropriate.]
pthread.h:
_EXT_PTHREAD_*_NP [for each _np function]
sched.h:
_EXT_CLONE (*)
_EXT_UNSHARE
_EXT_SETNS
_EXT_SCHED_GETCPU
_EXT_SCHED_GETAFFINITY
_EXT_SCHED_SETAFFINITY
[It's not clear whether clone (*) should be advertised at all until
there's some consensus on what parts of it can be used. These
interfaces also have rather generic names but Linux-specific meaning
such that they maybe should be qualified as Linux, e.g.
_EXT_LINUX_SETNS etc.]
stdio.h:
_EXT_PRINTF_FMT_m
[Availability of printf format extensions needs to be advertised here
too. Perhaps something like this.]
sys/mman.h:
_EXT_MREMAP
_EXT_MADVISE
_EXT_MINCORE
_EXT_MEMFD_CREATE
_EXT_MLOCK2
_EXT_REMAP_FILE_PAGES
[Some (most?) of these should perhaps be Linux-qualified since they
don't seem to be cross-platform agreements outside of Linux world.]
Note on naming: I just picked the _EXT_* convention because I'm not
aware of anything it conflicts with and it's very simple and
implementation-agnostic and does not come across as "slapping a brand
on things". Feel free to bikeshed if you have constructive ideas for
something better and a compelling reason that my choice is bad or that
yours is better.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
