From: Rich Felker <dalias@libc.org>
To: Jens Gustedt <Jens.Gustedt@inria.fr>
Cc: musl@lists.openwall.com, jens.gustedt@posteo.eu
Subject: Re: [musl] [C23 printf 2/3] C23: implement the wN length specifiers for printf
Date: Fri, 2 Jun 2023 10:38:00 -0400 [thread overview]
Message-ID: <20230602143759.GQ4163@brightrain.aerifal.cx> (raw)
In-Reply-To: <5a2c0731967330e9a3832d531ea4212e223aaead.1685429467.git.Jens.Gustedt@inria.fr>
On Tue, May 30, 2023 at 08:55:27AM +0200, Jens Gustedt wrote:
> These are mandatory for C23 and concern all types for which the
> platform has `int_leastN_t` and `uint_leastN_t`. For musl these types
> always coincide with `intN_t` and `uintN_t` and are always present for
> N equal 8, 16, 32 and 64.
>
> They can be added for general use since all lowercase letters were
> previously reserved.
>
> Nevertheless, users that use these modifiers will see a lot of
> warnings from compilers in the beginning. This is because the
> compilers have not yet integrated this form of a specifier into their
> correponding extensions (gcc attributes). So unfortunately also
> testing this feature may be a bit noisy for the moment.
>
> The only architecture dependend choice is the type for N == 64, which
> may be `long` or `long long`. We just mimick the test that is done in
> other places to compare `UINTPTR_MAX` and `UINT64_MAX` to determine
> that.
> ---
> src/stdio/vfprintf.c | 28 +++++++++++++++++++++++++---
> src/stdio/vfwprintf.c | 28 +++++++++++++++++++++++++---
> 2 files changed, 50 insertions(+), 6 deletions(-)
>
> diff --git a/src/stdio/vfprintf.c b/src/stdio/vfprintf.c
> index cbc79783..265fb7ad 100644
> --- a/src/stdio/vfprintf.c
> +++ b/src/stdio/vfprintf.c
> @@ -33,7 +33,7 @@
>
> enum {
> BARE, LPRE, LLPRE, HPRE, HHPRE, BIGLPRE,
> - ZTPRE, JPRE,
> + ZTPRE, JPRE, WPRE,
> STOP,
> PTR, INT, UINT, ULLONG,
> LONG, ULONG,
> @@ -57,7 +57,7 @@ static const unsigned char states[]['z'-'A'+1] = {
> S('s') = PTR, S('S') = PTR, S('p') = UIPTR, S('n') = PTR,
> S('m') = NOARG,
> S('l') = LPRE, S('h') = HPRE, S('L') = BIGLPRE,
> - S('z') = ZTPRE, S('j') = JPRE, S('t') = ZTPRE,
> + S('z') = ZTPRE, S('j') = JPRE, S('t') = ZTPRE, S('w') = WPRE,
> }, { /* 1: l-prefixed */
> S('b') = ULONG, S('B') = ULONG,
> S('d') = LONG, S('i') = LONG,
> @@ -101,6 +101,12 @@ static const unsigned char states[]['z'-'A'+1] = {
> S('o') = UMAX, S('u') = UMAX,
> S('x') = UMAX, S('X') = UMAX,
> S('n') = PTR,
> + }, { /* 8: w-prefixed */
> + S('b') = UINT, S('B') = UINT,
> + S('d') = INT, S('i') = INT,
> + S('o') = UINT, S('u') = UINT,
> + S('x') = UINT, S('X') = UINT,
> + S('n') = PTR,
> }
> };
>
> @@ -447,7 +453,7 @@ static int printf_core(FILE *f, const char *fmt, va_list *ap, union arg *nl_arg,
> int w, p, xp;
> union arg arg;
> int argpos;
> - unsigned st, ps;
> + unsigned st, ps, width=0;
> int cnt=0, l=0;
> size_t i;
> char buf[sizeof(uintmax_t)*CHAR_BIT+3+LDBL_MANT_DIG/4];
> @@ -527,9 +533,25 @@ static int printf_core(FILE *f, const char *fmt, va_list *ap, union arg *nl_arg,
> if (OOB(*s)) goto inval;
> ps=st;
> st=states[st]S(*s++);
> + if (st == WPRE) {
> + if (*s == '0') goto inval;
> + width = getint(&s);
> + }
> } while (st-1<STOP);
> if (!st) goto inval;
>
> + if (ps == WPRE) switch (width) {
> + case 8: ps = HHPRE; st = (st == UINT) ? UCHAR : ((st == INT) ? CHAR : PTR); break;
> + case 16: ps = HPRE; st = (st == UINT) ? USHORT : ((st == INT) ? SHORT : PTR); break;
> + case 32: ps = BARE; break;
> +#if UINTPTR_MAX >= UINT64_MAX
> + case 64: ps = LPRE; st = (st == UINT) ? ULONG : ((st == INT) ? LONG : PTR); break;
> +#else
> + case 64: ps = LLPRE; st = (st == UINT) ? ULLONG : ((st == INT) ? LLONG : PTR); break;
> +#endif
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.
Short of a compelling reason not to, though, I plan to just go with
the fix-up of my v2 patch for this functionality. Its ordering avoids
duplication of logic (the ?: branches in the cases above) and the need
for maintaining extra side state (the width variable) thru the state
machine.
Rich
next prev parent reply other threads:[~2023-06-02 14:38 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1685429467.git.Jens.Gustedt@inria.fr>
2023-05-30 6:55 ` [musl] [C23 printf 1/3] C23: implement the b and B printf specifiers Jens Gustedt
2023-05-30 6:55 ` [musl] [C23 printf 2/3] C23: implement the wN length specifiers for printf Jens Gustedt
2023-06-02 14:38 ` Rich Felker [this message]
2023-06-02 15:09 ` Jₑₙₛ Gustedt
2023-06-02 15:16 ` Rich Felker
2023-06-02 15:37 ` Jₑₙₛ Gustedt
2023-05-30 6:55 ` [musl] [C23 printf 3/3] C23: implement the wfN length modifiers " Jens Gustedt
2023-05-31 14:04 [musl] [C23 printf 0/3] to be replaced Jens Gustedt
2023-05-31 14:04 ` [musl] [C23 printf 2/3] C23: implement the wN length specifiers for printf Jens Gustedt
-- strict thread matches above, loose matches on Subject: below --
2023-05-26 19:41 [musl] [C23 printf 0/3] Jens Gustedt
2023-05-26 19:41 ` [musl] [C23 printf 2/3] C23: implement the wN length specifiers for printf Jens Gustedt
2023-05-26 20:31 ` Rich Felker
2023-05-26 20:51 ` Jₑₙₛ Gustedt
2023-05-26 21:03 ` Rich Felker
2023-05-29 7:14 ` Jₑₙₛ Gustedt
2023-05-29 15:46 ` Rich Felker
2023-05-29 19:21 ` Jₑₙₛ Gustedt
2023-05-30 1:48 ` Rich Felker
2023-05-30 6:46 ` Jₑₙₛ Gustedt
2023-05-30 17:28 ` Rich Felker
2023-05-30 18:00 ` Rich Felker
2023-05-31 7:59 ` Jₑₙₛ Gustedt
2023-06-02 14:29 ` Rich Felker
2023-06-02 14:55 ` Jₑₙₛ Gustedt
2023-06-02 15:07 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230602143759.GQ4163@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=Jens.Gustedt@inria.fr \
--cc=jens.gustedt@posteo.eu \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).