Newsgroups: comp.lang.c
Path: utzoo!henry
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: more on TRUE and FALSE (side-comment)
Message-ID: <1990Sep23.002920.16174@zoo.toronto.edu>
Organization: U of Toronto Zoology
References: <181@thor.UUCP> <14084:Sep2105:38:0890@kramden.acf.nyu.edu> <18097@haddock.ima.isc.com> <18292:Sep2203:27:3090@kramden.acf.nyu.edu>
Date: Sun, 23 Sep 90 00:29:20 GMT

In article <18292:Sep2203:27:3090@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>> #define STREQ(a,b)  ( *(a) == *(b) && !(*(a) && strcmp((a)+1, (b)+1)) )
>
>Yes, you're right. Sorry. Thanks also to Peter Montgomery for pointing
>this out. In any case it's better than the original macro, whether
>strcmp is inlined or not.

Nope, sorry, not clearly so.  We're not stupid; we thought of that.  The
question is whether doing a redundant test of the initial byte within
strcmp is really slower than the `*(a)' test plus two pointer increments.
Our conclusion was that it usually isn't... particularly if you have a
clever strcmp that does compares a word at a time, in which case you're
quite possibly fouling it up by ruining the alignment of the operands.
It certainly isn't a clear win, so the extra complexity is unjustified.
-- 
TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
OSI: handling yesterday's loads someday|  henry@zoo.toronto.edu   utzoo!henry