[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230503111246.00ba409e@inria.fr>
Date: Wed, 3 May 2023 11:12:46 +0200
From: Jₑₙₛ Gustedt <jens.gustedt@...ia.fr>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: patches for C23
Rich,
thanks for looking into this so quickly.
on Tue, 2 May 2023 20:00:45 -0400 you (Rich Felker <dalias@...c.org>)
wrote:
> Some more things I noticed, some of them general:
>
> For compiler feature stuff like __has_c_attribute, this should not be
> littered all over headers. We have features.h that already abstracts
> getting the ones we need. If there are others strictly needed, those
> should be abstracted there too.
ok, I'll see that I group things that are needed together, there.
> It's probably not needed to avoid exposing new functions under older
> __STDC_VERSION. We generally do not aim for strict namespace
> conformance to older versions of the standards.
ok, that's politics, if you think that this is fine I'll go for it
(Such a policy will be difficult to maintain, when there will be third
party implemenations of the decimal floating point stuff. This will be
some hundreds of new interfaces that had not been reserved. Also there
will be a bunch of such functions in `math.h` even without decimal
floating point which are not covered by these patches.)
> On the flip side, it's not needed to jump through compiler-specific
> hoops to get new features that can't be obtained in standard ways
> without c23 mode. For example, nullptr_t does not need clang special
> cases. If it's not c23, it just doesn't need to be defined (and in
> fact strictly speaking it's a namespace violation to define it, but as
> above we don't really care about that.)
I see your point. `nullptr` is special in that it might also be
provided as an extension in other standard modes by compilers, and
tendency in clang, for example, could be to base `NULL` on
that. Providing the `typedef` is then some nicety for our users.
> It's not needed to make namespace-safe internal __-prefixed versions
> of functions unless they're used to implement functions in a more
> restrictive namespace profile. For example, POSIX functions needed to
> implement STDC functions need this treatment, but STDC functions
> basically never do.
Ok, that simplifies things. And effectively this will give hard errors
for applications that already use such names, even if they are
dynamically linked.
This probably is a good thing.
> Language/compiler baseline for building musl is not going to go up, so
> this complicates some things, especially implementing the int128
> stuff. This will need pop_arg to call out to an arch-provided asm
> function that bypasses the C type system to get the nonexistent-type
> argument off the va_list and store it in a pair of uint64_t.
I don't see that. `pop_arg` just uses `va_arg` and that in turn is
fixed to `__builtin_va_arg`. The proposed patches assume that if
`__SIZEOF_INT128__` is defined by the compiler that then the compiler
provides the `__int128` types and knows how to deal with them in
`__builtin_va_arg`. Is there anything wrong with that assumtion?
> There are not going to be different versions of scanf/strto* because
> there's just no way to do that in a conforming way (the standard
> allows declaring these functions yourself without including the
> header, which would not get the remapping).
Yes, sure. Applications that do that would receive the default
treatment which is delivered with a given C library, much as for other
legacy objects that had been compiled with previous versions.
> As above, strict conformance to outdated versions of the standard is
> just not a priority. musl's claim/target is conformance to current
> versions only and sometimes, on a case-by-case basis, partial
> support for older ones.
Yes. But this here is really something to consider. Legacy executables
that are linked dynamically may behave semantically different with
this patch. This might even have security implications. E.g within
musl itself in inet_aton.c there is a use with a base of `0` that
could perhaps be abused to do spoofy things.
> (Looking at it again, I don't understand how the code in your
> repo was actually intended to provide different versions. __intscan,
> etc. are not public interface boundaries and references to them never
> appear in applications, only internally within libc. Your code seems
> to be conditioning which gets used based on the STDC version in use
> for building musl, which is completely decoupled from the version of
> the standard that a given application is being built/linked for.)
Yes, this is an attempt to cope with the situation, which is probably
not yet final. I was hestitating to do the work of duplicate all the
externally visible interfaces before we agree upon such an approach.
The idea is that a C library provider (i.e Linux distribution) would
have to decide which version to provide as a default for legacy
executables. (Here this is done by using the C version with which the
library is compiled, but other mechanisms would be possible.)
Newly compiled code (but for the extremists that you mentionned above)
would get the mode C17 or C23 under which they compile.
Jₑₙₛ
--
:: ICube :::::::::::::::::::::::::::::: deputy director ::
:: Université de Strasbourg :::::::::::::::::::::: ICPS ::
:: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus ::
:: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::
:: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Content of type "application/pgp-signature" skipped
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.
