[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 2 Jun 2023 09:58:14 +0200
From: Jₑₙₛ Gustedt <jens.gustedt@...ia.fr>
To: Szabolcs Nagy <nsz@...t70.net>
Cc: Rich Felker <dalias@...c.org>, musl@...ts.openwall.com
Subject: Re: Re: High-level C23 process requests
Szabolcs,
on Thu, 1 Jun 2023 20:22:23 +0200 you (Szabolcs Nagy <nsz@...t70.net>)
wrote:
> * Jₑₙₛ Gustedt <jens.gustedt@...ia.fr> [2023-06-01 08:58:42 +0200]:
> > Also, in the compiler community there does not seem to be much of a
> > resistance to implement C23. clang and gcc are almost complete and
> > probably will have all of C23 the day it will be officially
> > published. They will then probably switch to C23 as a default one or
> > two versions later, once the C library support is stable.
>
> well clang had _BitInt before it was in the standard..
this is just the hen-and-egg problem
WG14 wouldn't standardize if there is no experience in the field, the
field wouldn't dare to do anything novel if this is not imposed by
some standard. So glitches like that are built into the process,
luckily the clang people took the risk and went ahead to start it. (And
they paid quite a price, having to rename the type, for example.)
> which is a bit of a problem because ppl only now realize that its
> abi is not what they want so various targets try to retroactively
> specify the ps abi for it which may leave existing clang broken.
yes
This is also the principal reason, I think, why C23 doesn't impose
function interfaces for these types, not even `printf` or `scanf`
formats, nor for the new <stdbit.h> header. So all C libraries such as
musl that delegate `va_arg` to compiler buitins should not be affected
by this.
> in any case i think standard conformance is a good thing in musl, but
> we are not in a big hurry to implement c23, and can wait until clang
> and gcc converge on abi for a couple of targets.
As said, these ABI questions are not impacting C libraries. So I don't
see how this would be an argument for (or against) integrating the
things that we have, in particular the boring stuff. I am still much
in favor to integrate this as soon as it is ready, be it for the
simple reason to never talk about it again.
Since I have your attention, there is also other "boring" stuff that I
have not even tried to implement, most things concerning floating
point functions. These are
acospi, asinpi, atan2pi, atanpi, compoundn, cospi,
fmaximum_mag_num, fmaximum_mag, fmaximum_num, fmaximum,
fminimum_mag_num, fminimum_mag, fminimum_num, fminimum,
nextup, rootn, roundeven, sinpi, tanpi, fadd, dadd, fsub,
dsub, fmul, dmul, fdiv, ddiv
which get the usual three function interfaces and the tg-macro in
<tgmath.h>. For someone with experience in FP like you these are
probably not a big deal, it is just that there are finally a lot more
than I thought. I personnally don't think that I have the skills for
these functions.
Thanks
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.
