home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / c / 13259 < prev    next >
Encoding:
Internet Message Format  |  1992-09-07  |  3.1 KB
  1. Xref: sparky comp.lang.c:13259 comp.std.c:2573
  2. Newsgroups: comp.lang.c,comp.std.c
  3. Path: sparky!uunet!cs.utexas.edu!convex!news.oc.com!utacfd.uta.edu!rwsys!sneaky!gordon
  4. From: gordon@sneaky.lonestar.org (Gordon Burditt)
  5. Subject: Re: strcpy implementation question
  6. Message-ID: <Bu3DxM.I9D@sneaky.lonestar.org>
  7. Organization: Gordon Burditt
  8. References: <PINKAS.92Aug24183511@caraway.intel.com> <1992Aug26.224904.7671@sneaky.lonestar.org> <PINKAS.92Sep2173635@skywalker.intel.com>
  9. Date: Sat, 5 Sep 1992 06:27:05 GMT
  10. Lines: 54
  11.  
  12. >The source argument (the second argument) to strcpy is declared as 'const
  13. >char *', which states that the routine will not modify the source string.
  14.  
  15. No, it says it won't modify the source string *USING THAT POINTER*.
  16. It doesn't prevent it from getting at the source through global variables,
  17. destination pointers saved from previous calls, or just generally using
  18. system-dependent methods (the implementation of strcpy() doesn't have
  19. to be portable) to wipe the whole data segment.  
  20.  
  21. But I'd still consider any implementation of strcpy() that did these
  22. things non-conforming, even without a statement "thou shalt not mess up
  23. unrelated variables".
  24.  
  25. >> A better example would be the infamous "variable-length struct".
  26. >> You declare something like:
  27. >>     struct foo {
  28. >>         int    type;
  29. >>         ... bunch of other stuff here ...
  30. >>         char    name[1];
  31. >>     } *fp;
  32. >>     char    x[100];
  33. >> and then use it like:
  34. >>     fp = (struct foo *) malloc(sizeof(struct foo) + strlen(x));
  35. >>     strcpy(fp->name, x);
  36. >> "name" has supposedly known size.  x has supposedly known size.
  37. >> The compiler probably aligned both of them.  But if the copying stops 
  38. >> at 1 char or 1 word when x contains a 70-char string, I'm going to be 
  39. >> annoyed.  And a lot of programs will break.
  40.  
  41. >I don't know of a single compiler that guarantees to place two static
  42. >variables which are declared in the same file next to each other.  In other
  43. >words,
  44.  
  45. This example may be bogus, but not for this reason.  It does NOT assume
  46. that two static variables are next to each other.  (Which two?  There
  47. are only 2 choices, the source string and a pointer.  Neither is the
  48. destination.  And the program couldn't care less about those variables
  49. being next to each other.)  I didn't show the function header, but I 
  50. actually didn't intend that there be any static variables in the entire 
  51. program (global variables wouldn't have been indented - a style convention
  52. you can't depend on everyone using).  The storage allocated by one call 
  53. to malloc() is guaranteed to be contiguous (within itself).  The struct is 
  54. at the beginning of it.  The space allocated by malloc() is guaranteed 
  55. aligned properly.  The space computation guarantees that there's enough
  56. storage for the string that runs off the end of the struct.  If there is 
  57. extra padding inserted in the structure, that just gives extra margin for 
  58. the claim that it won't run off the end of allocated storage.
  59.  
  60. Ok, what IS bogus about this example?  (1) Running off the end of the
  61. name[] array, but I have assured that there IS enough storage following
  62. it to hold the data.  Is that good enough?  Any other complaints?
  63.  
  64.                     Gordon L. Burditt
  65.                     sneaky.lonestar.org!gordon
  66.