home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / c / 12856 < prev    next >
Encoding:
Text File  |  1992-08-27  |  3.0 KB  |  77 lines
  1. Newsgroups: comp.lang.c
  2. Path: sparky!uunet!newsgate.watson.ibm.com!yktnews!admin!curt
  3. From: curt@watson.ibm.com (Curt McDowell)
  4. Subject: Re: strcpy implementation question
  5. Sender: news@watson.ibm.com (NNTP News Poster)
  6. Message-ID: <1992Aug27.153441.29151@watson.ibm.com>
  7. Date: Thu, 27 Aug 1992 15:34:41 GMT
  8. Lines: 63
  9. Disclaimer: This posting represents the poster's views, not necessarily those of IBM
  10. References: <PINKAS.92Aug21114508@caraway.intel.com> <PINKAS.92Aug25163006@caraway.intel.com> <14213@goanna.cs.rmit.oz.au> <9224017.23144@mulga.cs.mu.OZ.AU>
  11. Nntp-Posting-Host: gorby.watson.ibm.com
  12. Organization: IBM T.J. Watson Research Center
  13.  
  14. In article <9224017.23144@mulga.cs.mu.OZ.AU>, fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
  15. > ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
  16. > >In article <PINKAS.92Aug25163006@caraway.intel.com>, pinkas@caraway.intel.com (Israel Pinkas) writes:
  17. > >> The fact that the memory has not been initialized is irrelevant.  If the
  18. > >> source didn't care about it, neither will the destination..
  19. > >
  20.  
  21. > >This is wrong.  It isn' the source or the destination that cares, it is
  22. > >strcpy() that cares.  strcpy() MUST NOT READ any uninitialised memory
  23. > >locations.
  24.  
  25. Well, I wouldn't state it that way.  I'd say it must not read anything
  26. outside of its own stack, global variables in the C library, or other memory
  27. it legally allocates.
  28.  
  29. > I'm sorry, but this is wrong.
  30. > The code to implement strcpy() does NOT have to be ansi-conformant - hell,
  31. > it doesn't even have to be written in C! It IS allowed to read
  32. > uninitialised memory locations, so long as that doesn't stop it doing its
  33. > job correctly.
  34. > 
  35. > The following function correctly implements strcpy on my machine:
  36. > 
  37. >     #define MINDLESS_USE_OF_UNITIALIZED_MEMORY 
  38. > 
  39. >     char *strcpy(char *dest, const char *src) {
  40. >         char *retval = dest;
  41. > 
  42. >     #ifdef MINDLESS_USE_OF_UNINITIALIZED_MEMORY
  43. >         char unused[4];
  44. >         unused[0] = (unused[1] *= (unused[2] += unused[3]));
  45. >     #endif
  46. > 
  47. >         while (*dest++ = *src++) ;
  48. >         return retval;
  49. >     }
  50. > 
  51. > It might not work on *your* machine, but that's irrelevant.
  52.  
  53. It better work on your machine.  "unused" is legally allocated local stack
  54. space, so of course you can reference it.  Since the initial contents are
  55. undefined, the result unused[0] is undefined.  Fine.
  56.  
  57. > If the compiler can determine that there referencing memory past
  58. > the end of the string will not cause any side-effects, then it is perfectly
  59. > entitled to do so.
  60.  
  61. No compiler can determine this for the general strcpy().
  62.  
  63. A good, portable strcpy MAY NOT access extra bytes before or after the
  64. source string, just the exact bytes of the string.  That's because the
  65. memory outside the string may be illegal address space, particularly
  66. where virtual memory or hardware parity checking is concerned, and you'd
  67. trap trying to read it.
  68.  
  69. You laugh.  Then, you write an optimized assembly memcpy() for a real
  70. C library.  Then.... you stop laughing  :-|
  71.  
  72. > Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
  73.  
  74. --
  75. Curt McDowell
  76. IBM T. J. Watson Research Center
  77.