From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3976 Path: news.gmane.org!not-for-mail From: John Spencer Newsgroups: gmane.linux.lib.musl.general Subject: Re: Optimized C memset Date: Tue, 27 Aug 2013 17:20:01 +0200 Message-ID: <521CC3A1.1050706@barfooze.de> 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> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1377617274 22803 80.91.229.3 (27 Aug 2013 15:27:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 27 Aug 2013 15:27:54 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3980-gllmg-musl=m.gmane.org@lists.openwall.com Tue Aug 27 17:27:57 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 1VELBV-0001Js-5X for gllmg-musl@plane.gmane.org; Tue, 27 Aug 2013 17:27:57 +0200 Original-Received: (qmail 25793 invoked by uid 550); 27 Aug 2013 15:27:56 -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 25767 invoked from network); 27 Aug 2013 15:27:56 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110221 SUSE/3.1.8 Mail/1.0 In-Reply-To: <20130827142159.GQ20515@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:3976 Archived-At: 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.