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.