Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 3 Sep 2019 12:13:39 +0200
From: Szabolcs Nagy <>
Subject: Re: About those weak aliases

* Rich Felker <> [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

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.