Date: Sun, 03 May 2020 21:24:52 +0200 From: Florian Weimer <fw@...eb.enyo.de> To: Rich Felker <dalias@...c.org> Cc: libc-coord@...ts.openwall.com Subject: Re: Macro-based advertisement of libc extensions * Rich Felker: > These should be modeled on the POSIX macros defined in unistd.h, like > _POSIX_MONOTONIC_CLOCK, _POSIX_TIMERS, _POSIX_SEMAPHORES, etc. and > should use a dedicated part of the reserved namespace like _EXT_* or > similar. Possibly this should include the semantics for definition > with a value of 0 ("supported for compilation and might or might not > be supported at runtime"), which may make sense for implementations > with different profiles or that only offer certain functionality > contingent on a kernel that supports it, etc. If that option is taken, > there could be corresponding sysconf (e.g. _SC_EXT_*) macros to query > availability at runtime, or a separate interface so as not to overload > sysconf. There might also be a chance here to convey that certain functions have only stub implementations and are not expected to be used at all (even though they are declared in headers and available for linking). > Implementation: > > I'm not particular about how this is done, but my leaning would be > either putting the macros in an existing standard header (preference: > unistd.h) or defining a single macro via a standard header that > advertises the presence of a second header they're all provided by. > Another option might be grouping them by functionality (i.e. stdio > extensions are advertised in stdio.h). The second header approach could make that header compatible with assembler language (.S) files, which could be beneficial in some cases. It would also help with processing for use with other programming languages than C. It also would provide a way to show which extensions could be made available conditionally with the right feature selection macros, rather than reflecting what is available with the current selection of these macros. More concretely, if I have to include <unistd.h> to see what I could get, then in this translation unit, I cannot feature-select the right version of <unistd.h> based on the information I just got from <unistd.h>. That is likely too ambitious in the first iteration (give that it would need some shared convention for feature selection macros), but maybe it's enough to sway things in favor of the separate header solution. With more widespread availability of __has_include, the bootstrap problem (that you have to include some header to learn of the feature description header) also goes away. > Open questons: > > What degree of compatibility do "equivalent" extensions need to be > advertised as the same? While I'd like part of the outcome of this > effort to be standardization of common extensions that are deemed to > be worth standardization (upstreaming in C or POSIX), I'm not > proposing running a parallel extra-standard standards organization. I expect that if there is divergence in implementations (and there always is), the existing standardization bodies will make up a new identifier, rather than picking a behavior and making other implementations non-conforming. An effort that does not aim at formal standardization does not have this kind of problem. > For extensions which already have multiple implementations, I think > the baseline macro should roughly mean "whatever is common between > historical implementations". If some implementations have additional > features (for example, accepting a null pointer) they can define in > addition to _EXT_FOO macros that advertise these additional properties > (in that example, _EXT_FOO_ACCEPTS_NULL). I trust that this is intended for cases like realpath, where the NULL argument has some useful meaning (and the difference is not “may crash” vs “is specified to fail with EINVAL”). > Where should common names be published? This probably requires some > sort of registry. A minimal version of that would just be posting > intent to this list and not having sustained well-motivated objection > to it. But maybe something more official/searchable/etc. makes sense. I guess we could have a neutral repository somewhere, where candidate implementations for feature flags are described. I think specification-by-example would be appropriate for this, particular if it is not a standardization effort (which would need real, implementation-indpeendent specification, of course). gnulib will likely provide a separate implementation of this, based on autoconf and other hacks, for C implementations that do not participate in this.
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.