[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230503141619.GW4163@brightrain.aerifal.cx>
Date: Wed, 3 May 2023 10:16:19 -0400
From: Rich Felker <dalias@...c.org>
To: Jₑₙₛ Gustedt <jens.gustedt@...ia.fr>
Cc: musl@...ts.openwall.com
Subject: Re: patches for C23
On Wed, May 03, 2023 at 11:12:46AM +0200, Jₑₙₛ Gustedt wrote:
> > 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?
Yes. We don't require a compiler that has an __int128. The feature set
of the library is not allowed to vary depending on the compiler
version it was built with. The only non-UB way to get an __int128 out
of a va_list if the compiler has no idea there's such a thing as
__int128 is to write asm that bypasses the C type system. There can be
a "generic" version of this TU, I guess, for archs where __int128 has
always been part of the arch ABI definition, that just uses a C
function calling va_arg; this would also be suitable for folks reusing
the code in places like wasm where an asm implementation isn't
suitable and where they have more control over the tooling.
> > 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.
One thing that could be done here, but I'm not sure if it's useful or
appropriate, is linking an object file defining a symbol named
something like __c23_profile with value 1 into the application or
shared library built in c23 mode. This would override (via
interposition) a definition with the value zero internal to libc, and
could be used to switch on incompatible features like this. I'm
skeptical whether this kind of thing is something we should do or want
to do, but it's at least something we could consider...
It seems unfortunate that the committee did not consider this
adequately. It would have made a lot more sense to leave the behavior
of base==0 alone and add new behaviors with base=-1 or something. But
FWIW the same kind of incompatible change already happened with
floating point in the past (strtod/scanf %e/f/g consuming hex floats
rather than reading "0x..." as 0) and the world didn't explode.
Rich
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.
