Path: utzoo!utgpu!cs.utexas.edu!sdd.hp.com!mips!apple!vsi1!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: alt.sources Subject: Re: Fast strcmp() wanted. Message-ID: <1990Oct4.180807.22050@zorch.SF-Bay.ORG> Date: 4 Oct 90 18:08:07 GMT References: <6003@hplabsz.HPL.HP.COM> <1145@exodus.Eng.Sun.COM> Organization: SF-Bay Public-Access Unix Lines: 29 falk@peregrine.Sun.COM (Ed Falk) writes: > sartin@hplabs.hp.com (Rob Sartin) writes: >> cedman@lynx.ps.uci.edu (Carl Edman) writes: >>>string structure (or better class, long live C++ ! :-) which calculates >>>a 32-bit CRC for each string the first time and stores it somewhere. >>>Then only 1 (inlined) longword-compare will do the stringcomparisons >>>for you. >> >>Afraid not. It'll give you an estimate of whether the strings match >>(correctly identifying those that don't). You will need to then >>actually compare the strings if they are the same. This method will >>also be unable to reproduce strcmp's behavior (strcmp returns a signed >>result indicated the <, =, > by being negative, zero, positive), it will >>only return a boolean (match, no match). > >Also, these two strings > > "ab\0x" > "ab\0y" > >(where x and y are any garbage that happens to be in memory after the >terminating '\0') will be evaluated as unequal. For an exclusive or or other 16 bit at a time checksum, perhaps, but a properly designed CRC (which is a bitwise operation on the string) would stop at the end of the byte before the null byte. Kent, the man from xanth.