Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!munnari.oz.au!metro!usage.csd.unsw.oz.au!spectrum!cameron
From: cameron@usage.csd.oz (Cameron Simpson,Uhmmm..???? Who knows)
Newsgroups: comp.std.c
Subject: Re: [m]allocation question
Message-ID: <871@usage.csd.unsw.oz.au>
Date: 29 Sep 90 05:41:34 GMT
References: <13946@smoke.BRL.MIL>
Sender: news@usage.csd.unsw.oz.au
Reply-To: cameron@spectrum.cs.unsw.oz.au (Cameron Simpson)
Organization: none
Lines: 26

From article <13946@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn):
| In article <UaxqffS00Vtq8akksB@andrew.cmu.edu> ghoti+@andrew.cmu.edu (Adam Stoller) writes:
|>        t = (struct node *) malloc(sizeof *t);
|>Isn't *t garbage at the time the sizeof is performed - isn't this
|>[almost?] de-referencing a NULL pointer.
| 
| We went through this about a year ago in a different guise.
| The outcome of that discussion was that, since the argument to sizeof
| is NOT evaluated, there is no attempt to access through that pointer,
| and only the type (not the value) of the hypothetical result is
| relevant.  Thus sizeof(*t) is obliged to work even if t contains a
| garbage value.

This interests me. I seem to recall an extended discussion (maybe in
comp.std.c) concerning ways to determine the size of a structure member.
I have been using the macro

    /* size of a field - may break under ANSI, but hasn't yet */
    #define		fsizeof(type,field) sizeof(((type *)NULL)->field)

for some time. I have recollections of remarks to the effect that the
above locution could break under a conformant compiler. Could someone
either correct me ("yes, Cameron, fsizeof() is ok") or re-iterate the
explaination of why this macro can break, while sizeof(*t) is fine.
	- Cameron Simpson
	  cameron@spectrum.cs.unsw.oz.au