[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zey17L_f3xGA8gOJ@voyager>
Date: Sat, 9 Mar 2024 20:18:04 +0100
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Cc: Andreas Schwab <schwab@...ux-m68k.org>, Rich Felker <dalias@...c.org>,
Guillem Jover <guillem@...rons.org>, libc-alpha@...rceware.org,
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
Am Sat, Mar 09, 2024 at 07:46:38PM +0100 schrieb Alejandro Colomar:
> Thanks. Then BSD extended the contract. That's still a problem of musl
> and glibc. The API is deficient without setprogname(3), and should be
> fixed. I think libc should either drop err.h and let another library
> take ownership of the API, or add a way to configure it, hopefully being
> compatible with the BSDs. No?
>
Well, that's the problem with library code. musl will never drop
existing functionality for ABI stability alone. The most that was ever
done was dropping the LFS64 symbols, and there the symbols are only
hidden from the linker, but the dynamic linker can still find them.
So no, musl will not be dropping the err.h functions. Of course, you can
install a library that overrides these symbols. libc is always linked in
last, and UNIX has a long and storied history of superseding symbols.
In this particular case, though, if BSD extended the contract, should
the onus of checking not be on the application? I think the application
should check whether the extended or basic contract is in effect.
Ciao,
Markus
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.
