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
