home *** CD-ROM | disk | FTP | other *** search
/ Source Code 1992 March / Source_Code_CD-ROM_Walnut_Creek_March_1992.iso / usenet / altsrcs / 1 / 1906 < prev    next >
Encoding:
Internet Message Format  |  1990-12-28  |  1.4 KB
  1. From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan)
  2. Newsgroups: alt.sources
  3. Subject: Re: Fast strcmp() wanted.
  4. Message-ID: <1990Oct4.180807.22050@zorch.SF-Bay.ORG>
  5. Date: 4 Oct 90 18:08:07 GMT
  6.  
  7. falk@peregrine.Sun.COM (Ed Falk) writes:
  8. > sartin@hplabs.hp.com (Rob Sartin) writes:
  9. >> cedman@lynx.ps.uci.edu (Carl Edman) writes:
  10. >>>string structure (or better class, long live C++ ! :-) which calculates
  11. >>>a 32-bit CRC for each string the first time and stores it somewhere.
  12. >>>Then only 1 (inlined) longword-compare will do the stringcomparisons
  13. >>>for you.
  14. >>
  15. >>Afraid not.  It'll give you an estimate of whether the strings match
  16. >>(correctly identifying those that don't).  You will need to then
  17. >>actually compare the strings if they are the same.  This method will
  18. >>also be unable to reproduce strcmp's behavior (strcmp returns a signed
  19. >>result indicated the <, =, > by being negative, zero, positive), it will
  20. >>only return a boolean (match, no match).
  21. >
  22. >Also, these two strings
  23. >
  24. >    "ab\0x"
  25. >    "ab\0y"
  26. >
  27. >(where x and y are any garbage that happens to be in memory after the
  28. >terminating '\0') will be evaluated as unequal.
  29.  
  30. For an exclusive or or other 16 bit at a time checksum, perhaps, but a
  31. properly designed CRC (which is a bitwise operation on the string) would
  32. stop at the end of the byte before the null byte.
  33.  
  34. Kent, the man from xanth.
  35. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
  36.