[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 6 Apr 2014 12:49:07 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: build with clang-3.4 warnings report
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
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.
