Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 6 Apr 2014 12:49:07 -0400
From: Rich Felker <>
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.


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.