Date: Sat, 16 Feb 2013 00:59:37 -0500 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: [PATCH 0/5] reorganize the use of weak symbols 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
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.