home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / c / 19233 < prev    next >
Encoding:
Internet Message Format  |  1993-01-05  |  1.4 KB
  1. Path: sparky!uunet!ogicse!news.u.washington.edu!cpac.washington.edu!mcglk
  2. From: mcglk@cpac.washington.edu (Ken McGlothlen)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Problem with string processing.
  5. Message-ID: <MCGLK.93Jan5005833@yang.cpac.washington.edu>
  6. Date: 5 Jan 93 08:58:33 GMT
  7. Article-I.D.: yang.MCGLK.93Jan5005833
  8. References: <1993Jan4.022737.19792@kpc.com> <2mqVwB6w165w@cybrspc.UUCP>
  9. Distribution: usa
  10. Organization: Dubious.
  11. Lines: 27
  12. NNTP-Posting-Host: yang.cpac.washington.edu
  13.  
  14. Roy M. Silvernail (roy%cybrspc@cs.umn.edu) writes:
  15. +----------
  16. | [regarding the C statment:  while (*ptr++ = *str++);  ]
  17. |
  18. | (nice touch, BTW) How does this differ from 'strcpy(ptr, str)' besides the
  19. | function call overhead?
  20. +----------
  21.  
  22. It doesn't.  In fact, that's often how strcpy() is implemented.
  23.  
  24. +----------
  25. | Assuming a large enough string for the append, and low-high byte ordering,
  26. | would this work?
  27. |
  28. | strcat(str,(char *)&ch);
  29. +----------
  30.  
  31. Well, it would work *sometimes*.  Remember that strcat() expects two pointers
  32. to ZERO-TERMINATED strings.  If what was stored in ch was immediately followed
  33. by a zero byte ('\0'), then it *would* work.  But ch is stored wherever the
  34. compiler wants to store it, and it could be followed by *anything*, which means
  35. that you could get a heck of a lot more characters on the end of str than you
  36. bargained for.
  37.  
  38.                 ---Ken McGlothlen
  39.                    mcglk@cpac.washington.edu
  40.                    mcglk@cpac.bitnet
  41.