home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / std / c / 3344 < prev    next >
Encoding:
Text File  |  1993-01-08  |  2.2 KB  |  49 lines
  1. Newsgroups: comp.std.c
  2. Path: sparky!uunet!gatech!rpi!usc!howland.reston.ans.net!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!princeton!csservices!kastle!blume
  3. From: blume@kastle.Princeton.EDU (Matthias Blume)
  4. Subject: Re: Struct hack one last time (one last time)
  5. Message-ID: <1993Jan8.153213.18742@csservices.Princeton.EDU>
  6. Sender: news@csservices.Princeton.EDU (USENET News System)
  7. Reply-To: blume@kastle.Princeton.EDU (Matthias Blume)
  8. Organization: Dept. of Computer Science, Princeton University
  9. References: <1993Jan7.221207.13818@leland.Stanford.EDU> <1993Jan8.065947.29719@sq.sq.com>
  10. Date: Fri, 8 Jan 1993 15:32:13 GMT
  11. Lines: 36
  12.  
  13. In article <1993Jan8.065947.29719@sq.sq.com>, msb@sq.sq.com (Mark
  14. Brader) writes:
  15. |> > ... Again, the basic question is still unresolved here: can a conversion
  16. |> > from one pointer type to another affect bytes other than those
  17. |> > where the pointer variable is stored?
  18. |> 
  19. |> There is nothing in the standard to justify such an action, so it
  20. |> would be permissible only under the "'as if' rule".  It could, for
  21. |> example, modify bytes that the program mustn't read because the
  22. |> behavior would be undefined, such as the bytes of an object of
  23. |> indeterminate value.  It could modify the bytes of a volatile object.
  24. |> But it could NOT modify some arbitrary object with a well-defined
  25. |> value that the program correctly expects to persist!
  26.  
  27. Agreed, so far.
  28.  
  29. |> 
  30. |> In particular, it could not modify padding at the end of a struct,
  31. |> precisely *because* it would break the struct hack.
  32.  
  33. Ok. Finally we have the explanation: the struct hack is legal, because
  34. otherwise it would be illegal. :)
  35.  
  36. Here is another explanation, why the compiler cannot add this kind of
  37. type-check
  38. information:  Malloc can (and often does) allocate a whole array of structures.
  39. It cannot write the information to the end of *all* the structures (since it
  40. does not know the number of elements).  The only solution would be to write
  41. the information whenever a new pointer value to one of these structures
  42. gets created (via casting, assignment AND POINTER ARITHMETIC).  But then there
  43. is no point in keeping this information at all (because the whole idea was to
  44. *probe* this information instead of freshly generating it).
  45.  
  46. (More objections, Dave?)
  47.  
  48. -Matthias
  49.