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

[Alejandro Colomar <alx@kernel.org>]

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

Hi Rich,

On Sat, Mar 09, 2024 at 10:02:58AM -0500, Rich Felker wrote:
> > How about adding setprogname(3) (and getprogname(3)) to GNU and musl
> > libc?
> 
> I really don't think they meet the criteria for inclusion. They don't
> have historical cross platform precedent, they're not something we've
> hit existing applications failing to build for lack of, they don't let
> you do anything you couldn't already do, and the semantics would be
> unclear

I would ask the BSD authors of the API to learn all the implications of
the pair of functions.  I don't know them.  Maybe Guillem knows.

> (do they just configure the

> legacy err.h functions?

Why would you call err.h legacy?  What do you offer to use instead?
snprintf(3) + perror(3) + exit(3)?

How about bugs in such NIH cases?  You'd fix them in every project where
you've written the same bug?  That's why we have libraries.  I don't
mind if the entirety of err.h was moved to a liberr standalone library,
but you have kidnapped those APIs in libc.  Would you release them?

> set
> __progname/program_invocation_short_name? modify argv[0]?)

Would you promise to keep __progname/program_invocation_short_name as a
way to configure err.h in musl/glibc?  If so, then maybe one can write a
portable library that wraps the unportable set of libc's.  But since you
own err.h, _you_ must be the one making a contract.  It's up to you to
decide which contract you want to offer.  I suggest making the same
contract present in the BSDs.

> 
> The entire err.h function set in musl is 67 lines that compile down to
> less than 500 bytes of machine code. If there's not a portable way to
> configure them the way you want,

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).  In the BSD world, where these APIs
originated, they seem to be configurable portably (within BSDs).  And
with libbsd, you can get relative portability to other systems.

You have a problem when you want to call these functions in a core
package, like shadow, because some distributions refuse to include
libbsd in their core packages.

> and you refuse to run a configure
> script of some sort to determine if the setprogname function some
> systems need exists, the simpler solution,

I don't refuse to do that, but it means I also need to write code to
handle the case where it's not available, and do some non-portable stuff
in that case.

In fact, I'll need to do that anyway, at least for some years until all
systems I care about have a version of libc that has the functions.

But, I'd like to be able to remove that code in, say, 5 or 10 years from
now.

> rather than trying to get
> new contracts into libc and wait for them to be widely available, is
> to copy-and-paste those 67 lines and customize them as needed in your
> program, no?

I partially agree with you, in that I don't like adding new contracts
into libc.  But that contract was already added broken into glibc and
musl.  I suggest you remove err.h from libc, and let a standalone
library to implement them separately, allowing to configure them.

I don't agree with your suggestion of going the NIH way.

Maybe I'll push a bit harder for inclusion of libbsd in distributions.
Then it'll be the problem of distributors to either package libbsd, or
do a lot of work to patch projects to not rely on libbsd.  It's not a
bad idea, actually.

> 
> Rich

Have a lovely day!
Alex

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

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