From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3977 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Optimized C memset Date: Tue, 27 Aug 2013 11:34:54 -0400 Message-ID: <20130827153454.GT20515@brightrain.aerifal.cx> References: <20130827083020.GA4503@brightrain.aerifal.cx> <1377593575.25996.289.camel@eris.loria.fr> <20130827091730.GN20515@brightrain.aerifal.cx> <1377597040.25996.295.camel@eris.loria.fr> <20130827142159.GQ20515@brightrain.aerifal.cx> <521CC3A1.1050706@barfooze.de> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1377617705 27947 80.91.229.3 (27 Aug 2013 15:35:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 27 Aug 2013 15:35:05 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3981-gllmg-musl=m.gmane.org@lists.openwall.com Tue Aug 27 17:35:08 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1VELIR-0006oV-7Y for gllmg-musl@plane.gmane.org; Tue, 27 Aug 2013 17:35:07 +0200 Original-Received: (qmail 30063 invoked by uid 550); 27 Aug 2013 15:35:06 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 30047 invoked from network); 27 Aug 2013 15:35:06 -0000 Content-Disposition: inline In-Reply-To: <521CC3A1.1050706@barfooze.de> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3977 Archived-At: On Tue, Aug 27, 2013 at 05:20:01PM +0200, John Spencer wrote: > 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. Indeed, while it's tempting to do something like defining "repr32", "repr64", etc. types (with may_alias attribute) in a common header, I think it makes the code a lot less clear, and actually more difficult to maintain if requirements of individual translation units change (for example some want to use fixed bit sizes, others want to use system word size). What may be beneficial, however, is putting the logic for whether aliasing rule exemptions are possible at all, and the attribute to use to get them, into a shared header file. However I'm not convinced that this logic is anymore complex than "#ifdef __GNUC__", so I think for now I'd like to start off just doing it simple, and possibly switch later as more string functions are adapted to document their aliasing to the compiler. I've always found that if factoring out this kind of logic is beneficial, the right way to factor it emerges while actually implementing the code rather than by trying to guess ahead of time what will be best. Rich