Re: build with clang-3.4 warnings report

[Rich Felker <dalias@aerifal.cx>]

On Sun, Apr 06, 2014 at 06:37:19PM +0200, Jens Gustedt wrote:
> Am Samstag, den 05.04.2014, 21:57 -0400 schrieb Rich Felker:
> > As usual you're the master of preprocessor tricks. Overall I like it,
> > but it's still not as efficient as what we have now.
> 
> If space efficiency is really as important, you could be thinking of
> compressing all that strings, there is a lot of redundancy in the
> text.

*sigh* This was all discussed in the last bikeshed.

Compressing it just moves all the size from shared text to non-shared
data, not to mention adding the code size of a decompressor. And you
can't just decompress one string at a time in a small buffer because
the contract of musl's strerror is that the returned string is
immutable/permanently valid. This is necessary to make implementing
printf, strerror_r, etc. in terms of strerror possible, which in turn
is needed to make them efficient (otherwise you need a horrible retry
loop dynamically allocating larger buffer space, etc.)

The question is not whether space efficiency is really important, but
whether there's a justification for enlarging a function when the
increase in size has no practical benefits. And I think a majority of
our users would say the answer is no.

I agree that your version is mildly more elegant, and if I'd thought
of it first that's probably what I would have used from the beginning,
but I can't see explaining to users a size increase for the sake of
mild elegance.

Rich