From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25777 invoked by alias); 10 May 2015 00:15:07 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 35069 Received: (qmail 29927 invoked from network); 10 May 2015 00:14:55 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version:content-type; bh=Lqlt7G+uq67fM+sCDJjb+Jvt483T4nTz53bPUBg4qhQ=; b=QUCWwDp2YkoafYdBYe/PnTsJRcKswGNXdo9/+k0n9kBCGEDJZbpXGmY4JwChzhL3o7 4soFnzYu9/wQ0Sn3+fjM3wgLAynjkft0qp0OAlBQHP82Qi7Tz0KVu5i5oc9kbkcrbNHa q7f6PZ42eSqCehxvxK5PUMcPQpiEYyGNQwpYIvnQvPg97jixWe0m8e7jxoYyJvjOmJYh 5LpuI98VBxOLNRVOEGIu47s/i3Iyf3E4nwbDgv1xEApHiiVno2XHKEVUypRGTt7QmuGf f9wfC5V9E1ymvQGVhcjjaR9aoiMaevADCoytKTjn4DxkscoT64Lisuqbh+6mDiD2GpO5 RuNg== X-Gm-Message-State: ALoCoQlwBdjb/E27t1w7S4hotzDs3CT/aapdDoa2OsMEb49Io9bn4mry6Tng23uYVT9mg+57GVFh X-Received: by 10.202.183.214 with SMTP id h205mr3107562oif.87.1431216890904; Sat, 09 May 2015 17:14:50 -0700 (PDT) From: Bart Schaefer Message-Id: <150509171446.ZM15357@torch.brasslantern.com> Date: Sat, 9 May 2015 17:14:46 -0700 In-Reply-To: Comments: In reply to Mikael Magnusson "Re: PATCH: Don't treat NUL as a combining character" (May 10, 2:02am) References: X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh workers Subject: Re: PATCH: Don't treat NUL as a combining character MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On May 10, 2:02am, Mikael Magnusson wrote: } Subject: Re: PATCH: Don't treat NUL as a combining character } } > -#define IS_COMBINING(wc) (WCWIDTH(wc) == 0 && !iswcntrl(wc)) } > +#define IS_COMBINING(wc) (wc != 0 && WCWIDTH(wc) == 0 && !iswcntrl(wc)) } } Instead of making this path ever so slightly slower by adding an extra } test that only matters a fraction of the time I think the test would be no slower (or at least faster than what you have there) if you just put the wc != 0 as the last branch of the && chain? } could we actually make it wc > 127 instead? I don't know the definitive answer to that, but it seems it should also go at the end. We're really micro-optimizing here, though.