🚀 go-pugleaf

In article <531@gec-mi-at.co.uk> adam@gec-mi-at.co.uk (Adam Quantrill) writes:
 >
 >strcmp2(s1, s2)
 >register short int *s1, *s2;
 >{
 >	while (*s1 == *s2++)
 >		if (!((*s1++ & 255) && (*(char *)s1)))
 >			return(0);
 >	return(*s1 - *--s2);
 >}
 >
 >This relies on the fact that it doesn't matter if you compare the NULLs at the
 >end of two equal strings or not. We go along the string twice as fast because
 >of the 16 bit operations, although there is a slight penalty due to the extra
 >test. The alignment problem only comes in if either of 
 >the strings begins on an odd boundary, which is fairly unusual anyway. 
 >Also watch the last part of the 'if' condition - this won't work on 
 >some machines, you may have to add 1 to the pointer.
 >-- 
 >       -Adam.
 >
 >/* If at first it don't compile, kludge, kludge again.*/

This might work on some machines, but don't even think about it being
portable..  It isn't...  The most obvious problem will occur on any
machine where the order of bytes in an int variable is [low, high].
This will cause the last like to fail to return the correct greater/
lessthan result....

There's also the problem you mentioned about the odd int boundry.  It may
be "fairly unusual anyway" because your coding style tends to place
strings on even boundrys without even thinking about it.  I admit that
it hasn't happend in most of my code either, but if you just once tried
porting something that assumed even string boundrys to a compiler that
packs the static stings end to end, you'd realize this isn't a good idea.

}

--- 
John Stanley (john@viper.UUCP)
Software Consultant - DynaSoft Systems
UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john