Re: About those weak aliases

[Rich Felker <dalias@libc.org>]

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)
> 
> __pthread_mutex_lock is not used internally right now, but
> e.g. __pthread_mutex_timedlock is.

Indeed, it looks like commit df7d0dfb9c686df31149d09008ba92834bed9803
added it with an expectation that C11 threads would use it, but
instead mtx_lock just calls mtx_timedlock with a null timeout. Having
it around may be useful at some point though so I don't think it makes
sense to add noise removing it and possibly adding it back later.

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

Rich