[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230602151639.GS4163@brightrain.aerifal.cx>
Date: Fri, 2 Jun 2023 11:16:40 -0400
From: Rich Felker <dalias@...c.org>
To: Jₑₙₛ Gustedt <jens.gustedt@...ia.fr>
Cc: musl@...ts.openwall.com, jens.gustedt@...teo.eu
Subject: Re: [C23 printf 2/3] C23: implement the wN length specifiers
for printf
On Fri, Jun 02, 2023 at 05:09:26PM +0200, Jₑₙₛ Gustedt wrote:
> Rich,
>
> on Fri, 2 Jun 2023 10:38:00 -0400 you (Rich Felker <dalias@...c.org>)
> wrote:
>
> > The logic here for whether w64 is LPRE or LLPRE is wrong. The
> > condition for whether [u]int64_t is long or long long is not whether
> > uintptr_t or long long would be too wide (they never are, in our ABIs)
> > but whether long is long enough. All our [u]intN_t are the lowest-rank
> > type of the desired size, and this seems to be consistent with what
> > other implementations like glibc do.
>
> I probably copied that logic wrong from somewhere. Yes, right thing is
> probably just to compare to the new `ULONG_WIDTH` macro or so.
>
> One thing to think about could be to always map 64 to `long long`,
> just for this function here. This would always have the right size and
> representation. And since this is an implementation of the C library,
> we make the rules ;-)
Well, in musl we generally want the code to have well-defined behavior
even if it's inlined via LTO, where the types would mismatch. Note
that this is kinda a problem for scanf where va_arg is used with
void*, except that POSIX, conveniently, explicitly requires the C
(compiler) implementation accept mismatched va_arg types when both
types are pointers. This is a big hammer but it seems to be a
necessary assumption to admit implementing the %n$ form of scanf,
which POSIX requires.
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.
