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

[Benjamin Berg <benjamin@sipsolutions.net>]

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.

Benjamin