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.