[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 10 Mar 2024 14:01:18 +0000
From: NRK <nrk@...root.org>
To: Alejandro Colomar <alx@...nel.org>
Cc: Rich Felker <dalias@...c.org>, Guillem Jover <guillem@...rons.org>,
libc-alpha@...rceware.org, musl@...ts.openwall.com,
libbsd@...ts.freedesktop.org, "Serge E. Hallyn" <serge@...lyn.com>,
"Skyler Ferrante (RIT Student)" <sjf5462@....edu>,
Iker Pedrosa <ipedrosa@...hat.com>, Christian Brauner <christian@...uner.io>
Subject: Re: Re: Tweaking the program name for <err.h> functions
> 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
