[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <521CC3A1.1050706@barfooze.de>
Date: Tue, 27 Aug 2013 17:20:01 +0200
From: John Spencer <maillist-musl@...fooze.de>
To: musl@...ts.openwall.com
Subject: Re: Optimized C memset
On 08/27/2013 04:21 PM, Rich Felker wrote:
> One of the things I think our users like about musl versus glibc
> is that, for the vast majority of the code, you can fully determine
> what it's doing without reading other implementation-specific files
> that define magic macros for things you might not understand -- and
> that you can take the code and drop it into another project without
> having to find all the implementation-internal headers it depends on.
>
> If something needs to be changed about the logic for may_alias, a
> simple grep -r will find all the source files it's in and makes it
> easy to change several occurrences. So I tend to think preserving
> readability and ease of reuse are more important than avoiding
> duplication, but if others agree with you, I wouldn't be entirely
> opposed to adding a "string_impl.h" or similar header with some shared
> preprocessor logic for all of the string functions that might be doing
> sketchy things with aliasing and alignment. I'd appreciate comments on
> this matter from others on which way we should go.
my feeling is that we should stick to our current policy of minor macros
being defined in the TUs that use them, making it both simpler to read,
and faster to compile (less work for the preprocessor).
sufficiently complex macros can go to internal headers instead, so
there's only one spot to be taken care of.
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.
