home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / std / c / 3350 < prev    next >
Encoding:
Internet Message Format  |  1993-01-09  |  1.4 KB
  1. Path: sparky!uunet!usc!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!ira.uka.de!Germany.EU.net!mikros!mwtech!martin
  2. From: martin@mwtech.UUCP (Martin Weitzel)
  3. Newsgroups: comp.std.c
  4. Subject: Re: Struct hack one last time (one last time)
  5. Message-ID: <1375@mwtech.UUCP>
  6. Date: 9 Jan 93 20:22:06 GMT
  7. References: <1993Jan7.221207.13818@leland.Stanford.EDU>
  8. Reply-To: martin@mwtech.UUCP (Martin Weitzel)
  9. Organization: MIKROS Systemware, Darmstadt/W-Germany
  10. Lines: 25
  11.  
  12. In article <1993Jan7.221207.13818@leland.Stanford.EDU> dkeisen@leland.Stanford.EDU (Dave Eisen) writes:
  13. [...]
  14. >This has nothing to do with malloc. The hypothetical compiler
  15. >could simply insert this error checking information whenever
  16. >it does a conversion from a (void *) to a (struct foo *). Again,
  17. >the basic question is still unresolved here: can a conversion
  18. >from one pointer type to another affect bytes other than those
  19. >where the pointer variable is stored?
  20.  
  21. Which directly brings up the question if (or if not) for
  22. any modifiable lvalue `x' and some `y' of the same type an
  23. assignment
  24.             x = y;
  25. may behave differently
  26. as a bitwise copy
  27.             memcpy(&x, &y, sizeof x);
  28.  
  29. (For the pedantics: Assume the appropriate header is included
  30. and the two objects do not overlap.)
  31.  
  32. To put it into the language of the standard: May some (otherwise
  33. strictly conforming) program change its behavior if the above
  34. two were switched.
  35. -- 
  36. Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
  37.