Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 10 Mar 2024 14:17:20 +0100
From: Alejandro Colomar <alx@...nel.org>
To: NRK <nrk@...root.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

Hi NRK,

On Sun, Mar 10, 2024 at 06:01:14AM +0000, NRK wrote:
> > What do you offer to use instead? snprintf(3) + perror(3) + exit(3)?
> 
> No need to have an intermediate buffer with snprintf when you can just
> use vfprintf directly.

For an interface that prefixes the program name, I need to either call
[v]fprintf(3) twice, or add locks; that is:

	lock()
	fprintf("%s: ", __progname);
	vfprintf(...);
	unlock();

or prepare the buffer and call it just once.

Because I want to call it as foo("reason");, not having to use
__progname all the time.

> 
> > I suggest you remove err.h from libc, and let a standalone library to
> > implement them separately, allowing to configure them.
> 
> These are not mutually exclusive. You can have err.h in libc while also
> having them as separate library.

If I #include <err.h>, glibc considers those as reserved names.

<https://www.gnu.org/software/libc/manual/html_node/Reserved-Names.html>

| All other library names are reserved if your program explicitly
| includes the header file that defines or declares them.

I guess it would work, because of weak symbols, but the manual
explicitly says don't do this.

> And besides, these are not good interfaces anyways. Aside from what Rich
> already said, you'll realize this soon when you need to use various
> posix_* or pthread_* functions which don't set the errno and instead
> return an error code.

There's errc(3), and also warnc() (Guillem, libbsd is missing the link
pages for warn*() variants!), to which you can pass an errno-like code.
This isn't supported by glibc, but is available in libbsd (and of
course, in the BSDs; at least I checked OpenBSD).

And for the finctions that don't report an errno-like, like the
gai_error(3) ones, you can use errx(3), and also warnx(3).  These are
supported in glibc.

So these are actually quite well suited for different kinds of error-
reporting functions.

Regarding multi-threaded programs:

If you're recommending writing a version because it's easy, but then
you say it needs locking, well, I wouldn't say writing a locking version
is easy.

> 
> Also, I don't think your fear of "NIH bug" is well grounded. This is not
> some highly complicated error-prone code, it's just simple logging
> facility.

locking code is error-prone, I'd say.

> 
> I am aware that there exists certain programming cultures [*] where
> having to write code instead of "import leftpad" is seen as taboo of the
> highest order. But in this case you don't even *have to* write anything
> when you can just copy err.c from musl and customize it.

I think the BSD err.h functions are actually quite well designed for
single-threaded programs (still the vast majority of software).

And for multi-threaded versions, we just need to convince the BSD
maintainers that they need to add locking.  If glibc and musl don't
consider these APIs as useless and legacy, and fix them, then maybe the
BSDs follow.

Again, is there anything better in glibc or musl?
Something that prefixes "$progname: " and appends the errno message?

Yeah, you could write fprintf("%s: ...", program_invocation_short_name,
...) all the time?  or write a wrapper that calls
fprintf("%s: ", program_invocation_short_name), but then you need to add
locking?  and then you need to set program_invocation_short_name = "su"?
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?
Oh well, you're basically writing the err.h interface.  The interface is
good.  It's the implementation that has small problems, but I say let's
fix them.  This is certainly not what I want to be doing for every
project.

And as said above, having an overlay library that defines err.h is a
violation of glibc's reserved names.  Not too bad if done in a library,
but certainly not that I'd do in every project.

Have a lovely day!
Alex

> 
> (* Counterculture to this also exists, such as Go's "A little copying
> is better than a little dependency" proverb for example.)
> 
> - NRK

-- 
<https://www.alejandro-colomar.es/>

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

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.