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

[NRK <nrk@disroot.org>]

>  or add locks; that is:
> 
> 	lock()
> 	fprintf("%s: ", __progname);
> 	vfprintf(...);
> 	unlock();
>
> [...]
>
> locking code is error-prone, I'd say.

These interfaces do not guarantee the output to be atomic. If you were
expecting it to be atomic then that's just *another* reason to roll it
yourself because a good ton of existing implementation doesn't lock.

https://github.com/bminor/musl/blob/master/src/legacy/err.c
https://github.com/freebsd/freebsd-src/blob/main/lib/libc/gen/err.c
https://github.com/openbsd/src/blob/master/lib/libc/gen/verr.c
https://cgit.freedesktop.org/libbsd/tree/src/err.c

musl doesn't, freebsd doesn't, openbsd doesn't, libbsd doesn't. Out of
the 5 implementations I checked, only glibc seems to lock.

> There's errc(3)

Which doesn't exist on musl, I don't think it exists on glibc either. So
you're back to "DIY or depend on libbsd" land if you use this function.

> Again, is there anything better in glibc or musl?
> Something that prefixes "$progname: " and appends the errno message?
> [...]
> And then add *c() for functions that return an errno-like code? And
> then add *x() variants for functions that don't use errno-like codes?

glibc has error(3), and program_invocation_name(3) to customize $progname.
Interface wise, I find it more pleasant than the err.h gang. Having an
explicit `errnum` argument serves all 3 usecases (no errno, errno,
errno-like return code) without having multiple functions with
x/y/z/c suffix.

(One issue I have with glibc's error() interface is that doing both
warning and fatal error through same function weakens static analyzers.
I'd split up the two and mark the fatal version with _Noreturn for
better warnings/static-analysis.)

But this function is even less portable (no musl or *BSD support last I
checked). So you're back to square one.

- NRK