Re: About those weak aliases

[Szabolcs Nagy <nsz@port70.net>]

* Markus Wichmann <nullplan@gmx.net> [2019-09-05 18:50:08 +0200]:

> On Mon, Sep 02, 2019 at 10:10:10PM +0200, Szabolcs Nagy wrote:
> > * Markus Wichmann <nullplan@gmx.net> [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.

can you show an example use of open in musl code
where it is called form an api implementation
that is defined by iso c?

> 
> 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.

since it is for namespacing, which one is used
is determined by the namespace rules.

for the dynamic linker it does not matter which
one is used, unless that code can get static
linked into an executable (dlstart.c or in the
future if dlopen is supported with static linking),
then the namespace clean variant (__mmap) must
be used.

> 
> > there are other usage of weak symbols, there was a patch
> > that tried to cathegorize them:
> >
> > https://www.openwall.com/lists/musl/2013/02/15/1
> >
> 
> That thread talks about pretty much every use of weak aliases except the
> type at issue here.
> 
> Ciao,
> Markus