home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / std / c / 3334 < prev    next >
Encoding:
Text File  |  1993-01-07  |  2.2 KB  |  48 lines
  1. Newsgroups: comp.std.c
  2. Path: sparky!uunet!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: <1993Jan7.210924.10032@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.200813.10289@leland.Stanford.EDU>
  10. Date: Thu, 7 Jan 1993 21:09:24 GMT
  11. Lines: 35
  12.  
  13. In article <1993Jan7.200813.10289@leland.Stanford.EDU>,
  14. dkeisen@leland.Stanford.EDU (Dave Eisen) writes:
  15. |> In article <1993Jan7.145117.8220@jarvis.csri.toronto.edu>
  16. flaps@dgp.toronto.edu (Alan J Rosenthal) writes:
  17. |> >steve@taumet.com (Steve Clamage) writes:
  18. |> >>An implementation is allowed to add padding to the end of a struct.
  19. |> >>Suppose that the implementation adds space to the end of each struct
  20. |> >>type where it encodes information used for run-time error checking.
  21. |> >
  22. |> >Can't do that... what happens when you malloc one of them?
  23. |> >
  24. |> >    struct whatever *p = (struct whatever *)malloc(sizeof(struct whatever));
  25. |> >
  26. |> >Immediately after the malloc, if p is not null you can start using
  27. the struct,
  28. |> >but it won't have that run-time-error-checking information, so it
  29. will fault.
  30. |> 
  31. |> I don't know whether or not implementations are allowed to
  32. |> do what Steve is suggesting here, but I don't think this
  33. |> is a reason why it couldn't. Couldn't the compiler, as part
  34. |> of the code it emits to convert the (void *) returned by
  35. |> malloc also emit instructions to set up the information that
  36. |> Steve is postulating here? Or is there language in the the
  37. |> standard that forbids a conversion from one pointer type to
  38. |> another to affect the block of memory to which this pointer 
  39. |> points?
  40.  
  41. How should the poor compiler know WHERE to insert that information.  For malloc
  42. there might be special handling in the compiler, but consider a library
  43. memory-allocation routine of my own that returns void * and which does not
  44. impose a simple relationship between arguments and the size of the
  45. chunk of memory allocated!
  46.  
  47. -Matthias
  48.