home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / c / 12932 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  2.3 KB
  1. Xref: sparky comp.lang.c:12932 comp.std.c:2534
  2. Newsgroups: comp.lang.c,comp.std.c
  3. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!convex!seas.smu.edu!utacfd.uta.edu!rwsys!sneaky!gordon
  4. From: gordon@sneaky.lonestar.org (Gordon Burditt)
  5. Subject: Re: strcpy implementation question
  6. Message-ID: <1992Aug26.224904.7671@sneaky.lonestar.org>
  7. Organization: Gordon Burditt
  8. References: <1992Aug23.003930.9918@saaf.se> <1992Aug23.194919.22007@iecc.cambridge.ma.us> <PINKAS.92Aug24183511@caraway.intel.com>
  9. Date: Wed, 26 Aug 1992 22:49:04 GMT
  10. Lines: 42
  11.  
  12. >That's the problem.  I claim that copying past the end of the string is
  13. >wrong, as the user may be building a string up backwards.  The compiler
  14. >writers claim that there is nothing in the ANSI spec that claims that the
  15. >memory past the destination's terminator is inviolate.
  16.  
  17. You won't find an explicit statement that the source string is inviolate,
  18. either.  (On destructive-read machines using, say, actual core memory, you
  19. might save time not re-writing the data you read.  This would be a very
  20. wierd "optimization".)  Nor is there a statement that argc or any other 
  21. random variable in the program is inviolate.  And there isn't any statement 
  22. that evaluating "1+2" doesn't launch missiles.  But there's not much point 
  23. in having a standard if doing anything can cause random side effects - the 
  24. standard uses terms like "undefined behavior" or "implementation-defined 
  25. behavior", and states limits on when these can happen.  Unless the source 
  26. and destination overlap, the behavior is supposed to be defined.
  27.  
  28. >2. The user may be relying on a side effect.  By only copying until the end
  29. >   of src, rather than until the end of the string, the string may not be
  30. >   completely copied.  For example:
  31.  
  32. A better example would be the infamous "variable-length struct".
  33. You declare something like:
  34.  
  35.     struct foo {
  36.         int    type;
  37.         ... bunch of other stuff here ...
  38.         char    name[1];
  39.     } *fp;
  40.     char    x[100];
  41.  
  42. and then use it like:
  43.  
  44.     fp = (struct foo *) malloc(sizeof(struct foo) + strlen(x));
  45.     strcpy(fp->name, x);
  46.  
  47. "name" has supposedly known size.  x has supposedly known size.
  48. The compiler probably aligned both of them.  But if the copying stops 
  49. at 1 char or 1 word when x contains a 70-char string, I'm going to be 
  50. annoyed.  And a lot of programs will break.
  51.  
  52.                     Gordon L. Burditt
  53.                     sneaky.lonestar.org!gordon
  54.