NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/std/c/3333

Text File | 1993-01-07 | 1.7 KB | 40 lines

Newsgroups: comp.std.c
Path: sparky!uunet!stanford.edu!nntp.Stanford.EDU!dkeisen
From: [e-mail] (Dave Eisen)
Subject: Re: Struct hack one last time (one last time)
Message-ID: <[e-mail]>
Sender: [e-mail] (Mr News)
Organization: Sequoia Peripherals, Inc.
Date: Thu, 7 Jan 93 20:08:13 GMT
Lines: 29

In article <[e-mail]> [e-mail] (Alan J Rosenthal) writes:
>[e-mail] (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?


--
Dave Eisen                               Sequoia Peripherals: [phone]
[e-mail]              Home:                [phone]
       There's something in my library to offend everybody.
          --- Washington Coalition Against Censorship