[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
