Re: [PATCH 0/5] reorganize the use of weak symbols

[Rich Felker <dalias@aerifal.cx>]

On Sat, Feb 16, 2013 at 12:22:03AM +0100, Jens Gustedt wrote:
> Weak symbols are used for several uses that are in fact quite distinct.

First some general comments -- I think this patchset might be arising
as a result of a clash of style/philosophy. As an analogy, "int" can
be be used for several things that are distinct. If there's a
possibility that int could be the wrong type on some systems or
configurations, it makes sense to use a typedef and a distinct type
name. But if int were already the correct type in all cases, using a
typedef just creates a barrier to reading comprehension in the code --
the reader has to go lookup what the type is defined as, only to find
that it's unconditionally "int". A great example of this kind of
obfuscation is glib.

In my view, what's going on here is in some ways similar. Weak aliases
are the right mechanism in all cases, but if you hide that with
different usage-specific macros, you create a barrier to reading where
the reader might think there's something more complicated going on
behind all the different macros.

As for weak functions rather than aliases, it was a conscious choice
early on to use a minimum number of gcc- or gnu-linker-specific
features. Unlike other weak symbol related features, weak aliases are
universally available on all unix-like toolchains; they were even part
of SVID, which specifies #pragma weak to define them; a C99 compiler
following this practice would necessarily need to support _Pragma
weak, which could be used to define the weak_alias macro in a
"portable" way. Whether there's any practical value now to minimizing
the use of non-essential gcc features is open to question, but I see
no need to gratuitously increase the number used.

With that said, one thing I highly agree with in your patchset is
documenting the different weak alias tricks used in musl --
specifically, commenting on which weak aliases are expected to be
replaced by strong definitions, and under what conditions those strong
definitions come into place.

I also can see some use for having common dummy functions, but I'd
have to review how you're proposing to do it because I remember
looking into this before and finding that it didn't work as I
expected. However, the savings are likely to be very small, since
dummy functions are typically just 1-2 bytes on x86 (depending on the
-mtune mode) and 4 bytes on risc archs.

I'll give a more detailed review of individual patches later; I just
wanted to get this email off so you have ideas early on where you're
probably going to run into differences of opinion.

Rich