Re: About those weak aliases

[Rich Felker <dalias@libc.org>]

On Tue, Sep 03, 2019 at 12:13:39PM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.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