From: David Laight <david.laight.linux@gmail.com>
To: Willy Tarreau <w@1wt.eu>
Cc: "Thomas Weißschuh" <linux@weissschuh.net>,
linux-kernel@vger.kernel.org, "Cheng Li" <lechain@gmail.com>
Subject: Re: [PATCH v4 next 09/23] tools/nolibc: Implement strerror() in terms of strerror_r()
Date: Sat, 7 Mar 2026 11:31:05 +0000 [thread overview]
Message-ID: <20260307113105.76fb7fe9@pumpkin> (raw)
In-Reply-To: <aav7gYgUY6Hq0H_w@1wt.eu>
On Sat, 7 Mar 2026 11:18:41 +0100
Willy Tarreau <w@1wt.eu> wrote:
> Hi David,
>
> On Mon, Mar 02, 2026 at 10:18:01AM +0000, david.laight.linux@gmail.com wrote:
> > From: David Laight <david.laight.linux@gmail.com>
> >
> > strerror() can be the only part of a program that has a .data section.
> > This requres 4k in the program file.
>
> Thanks for handling this one! Indeed, I saw a trivial hello world program
> take 4kB once %m got supported, which is a shame.
>
> > Add a simple implementation of strerror_r() (ignores buflen) and use
> > that in strerror() so that the "errno=" string is copied at run-time.
> > Use __builtin_memcpy() because that optimises away the input string
> > and just writes the required constants to the target buffer.
> >
> > Ignoring buflen is unlikely to be a problem given that the output is
> > always short.
>
> On this point it's not necessarily true, as we can overflow too short
> an output, e.g. when calling strerror_r() on a single-byte buffer:
But that would be silly, and you get what you deserve :-)
It's not like passing char[64] will be too short because of some overlong
error text.
>
> > +static __attribute__((unused,))
> > +int strerror_r(int errnum, char *buf, size_t buflen __attribute__((unused)))
> > +{
>
> Here I think we can simply do this to comply with the man page:
>
> if (buflen < 18) {
> errno = ERANGE;
> return -1;
Looks like it should 'return ERANGE' (matching glibc 2.13+).
> }
>
> (and we can safely ignore it for strerror()).
ISTR strerror_r() tends to get inlined into strerror() so it
would be optimised away.
That simple (slightly over-enthusiastic) check is probably fine.
Especially since normal code will be expecting a much longer string.
I did think of implementing strerror_r() as:
return snprintf(buf, buflen, "errno=%d", errnum) < buflen ? 0 : ERANGE;
but that seems excessive.
>
> > + __builtin_memcpy(buf, "errno=", 6);
> > + return 6 + i64toa_r(errnum, buf + 6);
> > +}
> > +
> (...)
>
> Thanks,
> Willy
next prev parent reply other threads:[~2026-03-07 11:31 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-02 10:17 [PATCH v4 next 00/23] Enhance printf() david.laight.linux
2026-03-02 10:17 ` [PATCH v4 next 01/23] tools/nolibc: Add _NOLIBC_OPTIMIZER_HIDE_VAR() to compiler.h david.laight.linux
2026-03-07 10:50 ` Willy Tarreau
2026-03-02 10:17 ` [PATCH v4 next 02/23] tools/nolibc/printf: Move snprintf length check to callback david.laight.linux
2026-03-07 10:48 ` Willy Tarreau
2026-03-02 10:17 ` [PATCH v4 next 03/23] selftests/nolibc: Return correct value when printf test fails david.laight.linux
2026-03-02 10:17 ` [PATCH v4 next 04/23] selftests/nolibc: check vsnprintf() output buffer before the length david.laight.linux
2026-03-02 10:17 ` [PATCH v4 next 05/23] selftests/nolibc: Use length of 'expected' string to check snprintf() output david.laight.linux
2026-03-02 10:17 ` [PATCH v4 next 06/23] selftests/nolibc: Check that snprintf() doesn't write beyond the buffer end david.laight.linux
2026-03-02 10:17 ` [PATCH v4 next 07/23] selftests/nolibc: Let EXPECT_VFPRINTF() tests be skipped david.laight.linux
2026-03-02 10:18 ` [PATCH 08/23] selftests/nolibc: Rename w to written in expect_vfprintf() david.laight.linux
2026-03-02 10:18 ` [PATCH v4 next 09/23] tools/nolibc: Implement strerror() in terms of strerror_r() david.laight.linux
2026-03-07 10:18 ` Willy Tarreau
2026-03-07 11:31 ` David Laight [this message]
2026-03-07 11:37 ` Willy Tarreau
2026-03-07 16:55 ` David Laight
2026-03-07 17:17 ` Willy Tarreau
2026-03-02 10:18 ` [PATCH v4 next 10/23] tools/nolibc: Rename the 'errnum' parameter to strerror() david.laight.linux
2026-03-07 10:19 ` Willy Tarreau
2026-03-02 10:18 ` [PATCH v4 next 11/23] tools/nolibc/printf: Output pad characters in 16 byte chunks david.laight.linux
2026-03-02 10:18 ` [PATCH 12/23] tools/nolibc/printf: Simplify __nolibc_printf() david.laight.linux
2026-03-02 10:18 ` [PATCH v4 next 13/23] tools/nolibc/printf: Use goto and reduce indentation david.laight.linux
2026-03-07 10:30 ` Willy Tarreau
2026-03-02 10:18 ` [PATCH 14/23] tools/nolibc/printf: Use bit-masks to hold requested flag, length and conversion chars david.laight.linux
2026-03-02 10:18 ` [PATCH v4 next 15/23] tools/nolibc/printf: Add support for length modifiers tzqL and formats iX david.laight.linux
2026-03-02 10:18 ` [PATCH v4 next 16/23] tools/nolibc/printf: Handle "%s" with the numeric formats david.laight.linux
2026-03-07 10:32 ` Willy Tarreau
2026-03-02 10:18 ` [PATCH 17/23] tools/nolibc/printf: Prepend sign to converted number david.laight.linux
2026-03-07 10:40 ` Willy Tarreau
2026-03-02 10:18 ` [PATCH v4 next 18/23] tools/nolibc/printf: Add support for conversion flags space and plus david.laight.linux
2026-03-07 10:46 ` Willy Tarreau
2026-03-02 10:18 ` [PATCH v4 next 19/23] tools/nolibc/printf: Special case 0 and add support for %#x david.laight.linux
2026-03-07 10:46 ` Willy Tarreau
2026-03-02 10:18 ` [PATCH v4 next 20/23] tools/nolibc/printf: Add support for left aligning fields david.laight.linux
2026-03-07 10:46 ` Willy Tarreau
2026-03-02 10:18 ` [PATCH v4 next 21/23] tools/nolibc/printf: Add support for zero padding and field precision david.laight.linux
2026-03-02 10:18 ` [PATCH v4 next 22/23] tools/nolibc/printf: Add support for octal output david.laight.linux
2026-03-07 10:45 ` Willy Tarreau
2026-03-02 10:18 ` [PATCH v4 next 23/23] selftests/nolibc: Use printf variable field widths and precisions david.laight.linux
2026-03-07 10:53 ` [PATCH v4 next 00/23] Enhance printf() Willy Tarreau
2026-03-07 18:02 ` Thomas Weißschuh
2026-03-07 22:03 ` David Laight
2026-03-07 22:20 ` Thomas Weißschuh
2026-03-08 9:23 ` Willy Tarreau
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=20260307113105.76fb7fe9@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=lechain@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=w@1wt.eu \
/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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox