[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 4 May 2023 10:07:30 -0400
From: Rich Felker <dalias@...c.org>
To: Gabriel Ravier <gabravier@...il.com>
Cc: musl@...ts.openwall.com,
Jₑₙₛ Gustedt <jens.gustedt@...ia.fr>
Subject: Re: patches for C23
On Thu, May 04, 2023 at 03:09:53AM +0200, Gabriel Ravier wrote:
> On 5/3/23 21:33, Rich Felker wrote:
> >On Wed, May 03, 2023 at 08:46:56PM +0200, Jₑₙₛ Gustedt wrote:
> >>Rich,
> >>
> >>on Wed, 3 May 2023 13:28:02 -0400 you (Rich Felker <dalias@...c.org>)
> >>wrote:
> >>
> >>>On Wed, May 03, 2023 at 05:11:11PM +0200, Jₑₙₛ Gustedt wrote:
> >>>>Rich,
> >>>>
> >>>>on Wed, 3 May 2023 10:16:19 -0400 you (Rich Felker
> >>>><dalias@...c.org>) wrote:
> >>>>>On Wed, May 03, 2023 at 11:12:46AM +0200, Jₑₙₛ Gustedt wrote:
> >>> [...]
> >>> [...]
> >>>>>Yes. We don't require a compiler that has an __int128.
> >>>>sure, but all the uses are protected by `__SIZEOF_INT128__`. So if
> >>>>the compiler don't has this, they will not see that code when
> >>>>compiling musl.
> >>>Again, there are not multiple versions of musl with different features
> >>>depending on which compiler was used to compile them. There is one
> >>>unified feature set. There are not configure-time or compile-time
> >>>decisions about which features to support.
> >>This sounds a bit dogmatic
> >Yes, it's one of the core principles of musl: that we don't have
> >build-time-selectable feature-set like uclibc did.
> >
> >>and also unrealistic. As said the dependency
> >>on compiler builtins undermines that approach. Future versions of gcc
> >>and clang will soon support `va_start` with only one parameter for
> >>example. Musl will just be dependent on that compiler feature.
> >No it won't. None of the code in musl calls or needs to call va_start
> >with one parameter. You're confusing header-level stuff that a c23
> >application might depend on, with build dependencies of libc.
> >
> >>How will you do with optional features, then? For example decimal
> >>floating point? This will never be added to musl? (Nobody will
> >>probably backport support for them to very old gcc versions, for
> >>example, or even to more recent versions of clang)
> >Decimal float math library will likely be left to a third-party
> >library implementation.
> >
> >Decimal float in printf, if that becomes a thing, will be done the
> >same way as int128: stub to pop the arguments, and 100% integer code
> >to actually work with the data.
> >
> >>>>Also application side compilation with a different compiler that has
> >>>>no `__int128` would not see these interfaces, so such application
> >>>>code can never call into the library with `__int128` types.
> >>>The compiler used to compile musl and the compiler used to compile the
> >>>application using musl have nothing to do with each other except
> >>>sharing a baseline ABI target.
> >>Yes, exactly. And one supporting `__int128` and the other that doesn't
> >>basically wouldn't interfere.
> >The premise here is that applications and libc are being built by
> >possibly different people with different tools. If I have a system
> >built with gcc 5.3, I can't build C23 applications, but I might get a
> >dynamically-linked C23 binary from someone who can. That binary needs
> >to run with my musl-1.2.7 (made-up number) libc.so because the C
> >language version the binary was generated from (or whether it was even
> >C at all) is irrelevant. The interface surface is just the musl ABI
> >surface.
> >
> >>For the support of `__int128`: gcc has this since ages on 64 bit
> >>archs, is there any such arch out there where this support is changing
> >>according to versions of gcc that are still in use? So if we make the
> >We also support pcc, cparser+libfirm, etc. on archs they support. Not
> >just gcc. And gcc back to 3.x.
> GCC 3.x ??? I understand wanting backwards compatibility but
> compiler versions from barely after the turn of the century seem
> like a bit far, I guess it's admirable that musl works with versions
> of software that are older than I am, but at some point I have to
> wonder if even a single person in the world actually finds it useful
> to be able to build musl with GCC 3 in 2023...
Yes, at least one and possibly several musl-based distros bootstrapped
with gcc 3 last time I checked.
In any case, you don't put "vastly narrowing the body of compilers you
can use to build musl" on the table as part of implementing new
functionality. This is how you get existing users to hate new
functionality.
More abstractly, we don't have "we support gcc 3 because it's gcc 3".
We have an extremely minimal set of requirements for compiler that
amount to "c99 plus an extremely small subset of 'gnu c' extensions"
and support any compiler that provides these, and gcc 3 happens to be
one of those. (So does pcc, etc.) The only times we've added
*anything* to the required set of extensions, to my recollection, has
been when the thing to be added was already known to be supported by
all existing compilers that already fit the requirements.
Now if there's a critical bug in a particular old compiler/version
that has it miscompiling musl, that doesn't mean we're going to go out
of our way to work around it. Likely it means anyone who wants to keep
using it needs to patch the bug. Again this is because our
requirements are based on standards/a baseline profile of what's
needed, not particular products and versions we've selected.
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.
