mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: NRK <nrk@disroot.org>
Cc: Rich Felker <dalias@libc.org>,
	Guillem Jover <guillem@hadrons.org>,
	libc-alpha@sourceware.org, musl@lists.openwall.com,
	libbsd@lists.freedesktop.org,
	"Serge E. Hallyn" <serge@hallyn.com>,
	"Skyler Ferrante (RIT Student)" <sjf5462@rit.edu>,
	Iker Pedrosa <ipedrosa@redhat.com>,
	Christian Brauner <christian@brauner.io>
Subject: Re: [musl] Re: Tweaking the program name for <err.h> functions
Date: Sun, 10 Mar 2024 14:17:20 +0100	[thread overview]
Message-ID: <Ze2y-UNcfLNZypYu@debian> (raw)
In-Reply-To: <vkjv3ntkak7egz6g7gpu7ojel6nvrjjcf4fq7iymatmn7qkoai@6onkgtmfjpgu>

[-- Attachment #1: Type: text/plain, Size: 4195 bytes --]

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/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2024-03-10 13:18 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Zeo-oJOyN9YQXVb1@debian>
     [not found] ` <ZepcO2pa0cwsqr3u@thunder.hadrons.org>
2024-03-08  0:52   ` Alejandro Colomar
2024-03-09 15:02     ` Rich Felker
2024-03-09 15:49       ` Alejandro Colomar
2024-03-09 18:35         ` Andreas Schwab
2024-03-09 18:46           ` Alejandro Colomar
2024-03-09 19:18             ` Markus Wichmann
2024-03-09 19:25             ` Rich Felker
2024-03-09 21:44         ` Thorsten Glaser
2024-03-10  6:01         ` NRK
2024-03-10 13:17           ` Alejandro Colomar [this message]
2024-03-10 14:01             ` NRK
2024-03-10 19:39               ` Rich Felker
2024-03-10 22:25                 ` Alejandro Colomar
2024-03-10 23:22                 ` Thorsten Glaser
2024-03-10 23:44                   ` Rich Felker
2024-03-11  0:19                     ` Thorsten Glaser
2024-03-11  0:46                       ` Alejandro Colomar
2024-03-11 14:46                         ` Skyler Ferrante (RIT Student)
2024-03-11 15:09                           ` Andreas Schwab
2024-03-11 15:30                             ` Skyler Ferrante (RIT Student)
2024-03-11 18:23                               ` Florian Weimer
2024-03-11 18:48                                 ` Skyler Ferrante (RIT Student)
2024-03-11 19:05                                   ` enh
2024-03-11 19:44                                     ` Rich Felker
2024-03-11 20:35                                       ` enh
2024-03-11 19:47                               ` Rich Felker
2024-03-11 20:08                                 ` Skyler Ferrante (RIT Student)
2024-03-11 20:39                                   ` enh
2024-03-11 21:21                                 ` Laurent Bercot
2024-03-11 22:05                                 ` Thorsten Glaser
2024-03-12  0:18                                 ` Gabriel Ravier
2024-03-12  0:43                                   ` Rich Felker
2024-03-12  3:23                                     ` Gabriel Ravier
2024-03-12 14:44                                       ` Rich Felker
2024-03-12 13:54                                   ` Florian Weimer
2024-03-12 14:21                                     ` Zack Weinberg
2024-03-12 14:31                                       ` Florian Weimer
2024-03-12 14:42                                         ` Rich Felker
2024-03-12 19:25                                           ` Zack Weinberg
2024-03-12 21:19                                             ` Rich Felker
2024-03-13  8:28                                             ` Florian Weimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Ze2y-UNcfLNZypYu@debian \
    --to=alx@kernel.org \
    --cc=christian@brauner.io \
    --cc=dalias@libc.org \
    --cc=guillem@hadrons.org \
    --cc=ipedrosa@redhat.com \
    --cc=libbsd@lists.freedesktop.org \
    --cc=libc-alpha@sourceware.org \
    --cc=musl@lists.openwall.com \
    --cc=nrk@disroot.org \
    --cc=serge@hallyn.com \
    --cc=sjf5462@rit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).