home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / c / 19282 < prev    next >
Encoding:
Internet Message Format  |  1993-01-06  |  1.5 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!wupost!csus.edu!netcom.com!netcomsv!ulogic!hartman
  2. From: hartman@ulogic.UUCP (Richard M. Hartman)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Problem with string processing.
  5. Message-ID: <811@ulogic.UUCP>
  6. Date: 6 Jan 93 01:44:52 GMT
  7. References: <1993Jan4.022737.19792@kpc.com> <2mqVwB6w165w@cybrspc.UUCP> <MCGLK.93Jan5005833@yang.cpac.washington.edu>
  8. Distribution: usa
  9. Organization: negligable
  10. Lines: 25
  11.  
  12. In article <MCGLK.93Jan5005833@yang.cpac.washington.edu> mcglk@cpac.washington.edu (Ken McGlothlen) writes:
  13. >Roy M. Silvernail (roy%cybrspc@cs.umn.edu) writes:
  14. >+----------
  15. >| [regarding the C statment:  while (*ptr++ = *str++);  ]
  16. >|
  17. >| (nice touch, BTW) How does this differ from 'strcpy(ptr, str)' besides the
  18. >| function call overhead?
  19. >+----------
  20. >
  21. >It doesn't.  In fact, that's often how strcpy() is implemented.
  22.  
  23. Actually, on systems w/ block memory move supported at the
  24. CPU level, memcpy() can be implemented much more efficently.
  25. If there were a decent way of getting the string length w/o
  26. counting all the bytes then direct support for strcpy() could
  27. be done easily.  Are there any CPUs that have a single-instruction
  28. way of saying "find the next 0 byte & tell me how far it was from here"?
  29.  
  30.  
  31.  
  32. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  33. And when you stop and think about it    |
  34. (you won't believe it's true)        |    -Richard Hartman    
  35. That all the love you've been giving    |    hartman@uLogic.COM
  36. has all been meant for you.        |
  37.