Re: [PATCH v2 03/11] tools/nolibc/stdio: remove perror if NOLIBC_IGNORE_ERRNO is set

[Willy Tarreau <w@1wt.eu>]

On Sun, Sep 21, 2025 at 07:16:50PM +0200, Benjamin Berg wrote:
> Hi,
> 
> On Sun, 2025-09-21 at 19:13 +0200, Willy Tarreau wrote:
> > On Sun, Sep 21, 2025 at 07:05:24PM +0200, Benjamin Berg wrote:
> > > This also ties to the question of the other mail. I prefer "errno" not
> > > to be available if it is not actually safe to use. UML does use threads
> > > in some places (and may use it extensively in the future). The current
> > > "errno" implementation is not threadsafe and I see neither an obvious
> > > way nor a need to change that. By setting NOLIBC_IGNORE_ERRNO any
> > > unsafe code will not compile and can be changed to use the sys_*
> > > functions to avoid errno.
> > 
> > That's the point I disagree with because here we're not using errno
> > more than printf() or dirent(). Why fix dirent() to build without errno
> > and break perror() ? Why not also break printf() then ? All of this must
> > be consistent. We're unbreaking some arbitrary functions and breaking
> > other arbitrary ones, that's not logical.
> > 
> > I'm totally fine with saying that errno shouldn't be defined when building
> > without errno, but all functions must continue to be defined. perror() is
> > used to print an error message, it's a valid use case just as printf() and
> > should remain.
> > 
> > If we disable perror for this, then we must also disable usage of printf
> > for consistency (and I don't want this either).
> 
> Right, fair enough. It is true that it does not really hurt to keep
> perror defined. I doubt there is much code out there, but I also don't
> really have a a strong argument against keeping perror. After all, it
> will "just" result in a bad error messages rather than undefined
> behaviour.

It shouldn't be a "bad" error message, just a limited one, which is the
main purpose of ignoring errno (i.e. where we're running we don't care
about error details since the user only needs to know that it failed, or
may even not know about it at all). perror *does* display the caller's
error message. I'm personally fine with seeing:

    "open(): unknown error"

for:

    if (open(path, O_RDONLY) < 0)
         perror("open()");

when building without errno.

Willy