Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 5 Sep 2019 18:50:08 +0200
From: Markus Wichmann <>
Subject: Re: About those weak aliases

On Mon, Sep 02, 2019 at 10:10:10PM +0200, Szabolcs Nagy wrote:
> * Markus Wichmann <> [2019-09-02 21:04:48 +0200]:
> > I'd like to know what those weak aliases are for in the many cases where
> > they are used to define a public interface. Or, more to the point, by
> > what criteria they are handed out, and by what logic the internal
> > symbols are used.
> >
> > For instance, pthread_mutex_lock() et al. are weakly defined, but
> it's a weak alias for __pthread_mutex_lock which can be used
> to implement iso c apis (where pthread* is not reserved and
> thus may conflict with user defined symbols)

Yes, namespacing, I thought so. But this style is not used consistently.
For example, open() does not go that route, even though the name is not
reserved in ISO 9899.

The other issue is, if two versions of a symbol exist, which one is
referenced internally. It seems musl mostly tries to use the internal
(strong) symbol, but not always. mmap() has the same mechanism in use,
but the dynamic linker references the weak version.

> there are other usage of weak symbols, there was a patch
> that tried to cathegorize them:

That thread talks about pretty much every use of weak aliases except the
type at issue here.


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.