Date: Tue, 3 Sep 2019 08:08:55 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: About those weak aliases On Tue, Sep 03, 2019 at 12:13:39PM +0200, Szabolcs Nagy wrote: > * Rich Felker <dalias@...c.org> [2019-09-02 19:01:18 -0400]: > > On Mon, Sep 02, 2019 at 10:10:10PM +0200, Szabolcs Nagy wrote: > > > (could be a strong alias, weakness of public api symbols > > > doesn't matter, you can only observe the difference by > > > getting a link error when static linking a conflicting > > > definition, but that is non-standard: when the symbol is > > > reserved for the implementation user code must not use it) > > > > I don't follow here. There are very few if any places where strong > > alias would be a valid substitute for weak. Where weak aliases provide > > dummy implementations of functionality that's only needed if something > > else is linked, strong would be a link error if both were linked. > > Where weak aliases are used because the identifier being defined is > > reserved to the application in some or all standard profiles, a strong > > alias would produce a link error if the application actually made use > > of its reservation and the file defining the alias got linked (and the > > whole point is that this can and does happen). > > you are right. sorry No problem. It's informative for uncovering if there are such cases and what they're for. I think the only places strong aliases would be okay is when the alias is providing a public interface and it's in the same namespace (or a more restrictive implementation namespace) as the symbol it's aliasing. These are mostly glibc ABI-compat symbols where the glibc ABI had __-prefixed versions of some public function as a public ABI (e.g. the __-prefixed versions of the 'xlocale' functions, __isoc99_*scanf, __getdelim; maybe nothing else). Rich
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.