Re: [musl] Re: Tweaking the program name for <err.h> functions

[Rich Felker <dalias@libc.org>]

On Sat, Mar 09, 2024 at 07:46:38PM +0100, Alejandro Colomar wrote:
> Hi Andreas,
> 
> On Sat, Mar 09, 2024 at 07:35:27PM +0100, Andreas Schwab wrote:
> > On Mär 09 2024, Alejandro Colomar wrote:
> > 
> > > There's not a portable way to configure them, AFAIK.  You could say it's
> > > glibc and musl's fault, for importing the err.h functions without
> > > importing setprogname(3).
> > 
> > When glibc imported err, setprogname didn't exist yet.
> 
> Thanks.  Then BSD extended the contract.  That's still a problem of musl
> and glibc.  The API is deficient without setprogname(3), and should be
> fixed.  I think libc should either drop err.h and let another library
> take ownership of the API, or add a way to configure it, hopefully being
> compatible with the BSDs.  No?

libc can't drop anything at the binary level because that's breaking
existing dynamic linked programs. It could remove the header, but that
has its own problems.

The err.h interfaces are called "legacy" in musl (appearing in
src/legacy) because they are not part of any standard and are just
something a bunch of ancient crufty code used and assumed was there.
They were added to musl early on (back in 2011) because they were
very-low-cost to add, no interaction with anything else (they didn't
even support progname at the time), and made it easier for people who
were getting musl-based systems up for the first time. They don't do
anything significant you can't do yourself with fprintf/perror, the
err forms exit without giving you any opportunity for clean exit
(except installing atexit handlers, which are their own mess of global
state), and as implmented aren't really multithread-friendly (they
don't lock around the multiple stdio calls to make the error output
atomic). Basically, they just go with a really, really antiquated
programming model, and do not seem like the sort of thing anyone
should be investing development time into improving *or* intentionally
breaking.

I agree there are sometimes hazards to copy-and-paste, but in the case
of these, a copy-and-paste version (or just a rewrite) where you can
wire up your own better behaviors more suited to your application is
really *better* than using them as-is. If you have your own header and
definition for these functions, the ones in libc will not even get
used. There is no "ownership" conflict.

Rich