home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / c / 12866 < prev    next >
Encoding:
Text File  |  1992-08-27  |  3.2 KB  |  79 lines
  1. Newsgroups: comp.lang.c
  2. Path: sparky!uunet!munnari.oz.au!cs.mu.OZ.AU!fjh
  3. From: fjh@cs.mu.OZ.AU (Fergus Henderson)
  4. Subject: Re: strcpy implementation question
  5. Message-ID: <9224103.3422@mulga.cs.mu.OZ.AU>
  6. Organization: Computer Science, University of Melbourne, Australia
  7. References: <PINKAS.92Aug21114508@caraway.intel.com> <PINKAS.92Aug25163006@caraway.intel.com> <14213@goanna.cs.rmit.oz.au> <9224017.23144@mulga.cs.mu.OZ.AU> <1992Aug27.153441.29151@watson.ibm.com>
  8. Date: Thu, 27 Aug 1992 17:45:03 GMT
  9. Lines: 68
  10.  
  11. curt@watson.ibm.com (Curt McDowell) writes:
  12.  
  13. >> The code to implement strcpy() does NOT have to be ansi-conformant - hell,
  14. >> it doesn't even have to be written in C! It IS allowed to read
  15. >> uninitialised memory locations, so long as that doesn't stop it doing its
  16. >> job correctly.
  17. >> 
  18. >> The following function correctly implements strcpy on my machine:
  19. >> 
  20. >>     #define MINDLESS_USE_OF_UNITIALIZED_MEMORY 
  21. >> 
  22. >>     char *strcpy(char *dest, const char *src) {
  23. >>         char *retval = dest;
  24. >> 
  25. >>     #ifdef MINDLESS_USE_OF_UNINITIALIZED_MEMORY
  26. >>         char unused[4];
  27. >>         unused[0] = (unused[1] *= (unused[2] += unused[3]));
  28. >>     #endif
  29. >> 
  30. >>         while (*dest++ = *src++) ;
  31. >>         return retval;
  32. >>     }
  33. >> 
  34. >> It might not work on *your* machine, but that's irrelevant.
  35. >
  36. >It better work on your machine.  "unused" is legally allocated local stack
  37. >space, so of course you can reference it.  Since the initial contents are
  38. >undefined, the result unused[0] is undefined.  Fine.
  39.  
  40. Well, NOT fine, if you were trying to write strictly conformant ANSI
  41. C code. An ANSI C implementation is well within its rights to dump core
  42. if you reference uninitialised memory - the idea is that some machines may
  43. have a special bit-pattern to represent uninitialised memory, and referencing
  44. this causes a trap.
  45.  
  46. >> If the compiler can determine that there referencing memory past
  47. >> the end of the string will not cause any side-effects, then it is perfectly
  48. >> entitled to do so.
  49. >
  50. >No compiler can determine this for the general strcpy().
  51.  
  52. Yes it could!
  53.  
  54. >A good, portable strcpy MAY NOT access extra bytes before or after the
  55. >source string, just the exact bytes of the string.  That's because the
  56. >memory outside the string may be illegal address space, particularly
  57. >where virtual memory or hardware parity checking is concerned, and you'd
  58. >trap trying to read it.
  59.  
  60. As I said above, even simply accessing uninitialized memory may cause a trap.
  61.  
  62. On the other hand, if you are NOT concerned with writing a portable strcpy,
  63. and you (or the compiler) know that accessing memory after the string will
  64. not causes a trap (or any other similar problem) then you are quite
  65. entitled to access that memory. There are machines that have neither
  66. virtual memory nor hardware parity checking, and for which READING memory
  67. NEVER causes any side-effects.
  68.  
  69. -- 
  70. Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
  71. This .signature VIRUS is a self-referential statement that is true - but 
  72. you will only be able to consistently believe it if you copy it to your own
  73. .signature file!
  74. -- 
  75. Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
  76. This .signature VIRUS is a self-referential statement that is true - but 
  77. you will only be able to consistently believe it if you copy it to your own
  78. .signature file!
  79.