🚀 go-pugleaf

In article <1993Jan7.200813.10289@leland.Stanford.EDU>,
dkeisen@leland.Stanford.EDU (Dave Eisen) writes:
|> In article <1993Jan7.145117.8220@jarvis.csri.toronto.edu>
flaps@dgp.toronto.edu (Alan J Rosenthal) writes:
|> >steve@taumet.com (Steve Clamage) writes:
|> >>An implementation is allowed to add padding to the end of a struct.
|> >>Suppose that the implementation adds space to the end of each struct
|> >>type where it encodes information used for run-time error checking.
|> >
|> >Can't do that... what happens when you malloc one of them?
|> >
|> >	struct whatever *p = (struct whatever *)malloc(sizeof(struct whatever));
|> >
|> >Immediately after the malloc, if p is not null you can start using
the struct,
|> >but it won't have that run-time-error-checking information, so it
will fault.
|> 
|> I don't know whether or not implementations are allowed to
|> do what Steve is suggesting here, but I don't think this
|> is a reason why it couldn't. Couldn't the compiler, as part
|> of the code it emits to convert the (void *) returned by
|> malloc also emit instructions to set up the information that
|> Steve is postulating here? Or is there language in the the
|> standard that forbids a conversion from one pointer type to
|> another to affect the block of memory to which this pointer 
|> points?

How should the poor compiler know WHERE to insert that information.  For malloc
there might be special handling in the compiler, but consider a library
memory-allocation routine of my own that returns void * and which does not
impose a simple relationship between arguments and the size of the
chunk of memory allocated!

-Matthias