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

[Thomas Weißschuh]

On 2025-09-21 19:13:23+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.

printf() is already broken. So by breaking perror() it would have been
consistent :-/.

> 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).

Then let's also fix printf(). Benjamin, do you want to add this to your
series? It should be consitent with the perror() fallback.


Thomas