🚀 go-pugleaf

Igor Postelnik (igor@natinst.com) writes:
> 	int *ip;
> 	void *vp1, *vp2;
> 	... some code where vp1 is made to point to valid memory ...
> 	ip = (int *)vp1;	/* 1 */
> 	vp2 = ip;		/* 2 */
> 
> Question: assuming vp1 is alligned properly to allow line 1, do vp2
> and vp1 carry the same information after line 2.

Yes.  The reference to "code where vp1 is made to point to valid memory
... aligned properly" effectively means that vp1 received its value from
an int * (call it ip0) or something with equivalent guarantees.  In other
words, the behavior is as if vp1 had received its value from a hypothetical
ip0.  Now 6.2.2.3 says that a pointer to any incomplete or object type may
be converted to a pointer to void and back again and the result compares
equal; that means that ip and ip0 are equal.  Then so are (void *)ip, i.e.
vp1, and (void *)ip0, i.e. vp2.

Note incidentally that the term "cast" refers to a particular syntax for
a type conversion; line 1 uses a cast, while line 2 does not.  The cast on
line 1 is redundant; some conversions may be expressed only by a cast, but
this is not one of them.  Of course, some people prefer to use casts even
when redundant, in the peculiar belief that this is good style.


> It is a widespread trick to implement variable length structures by
> declaring
> 
> 	struct x {
> 		int len;
> 		char data[1];
> 	};

This trick (with the associated malloc()) is often called "the struct hack".

> Now, the C FAQ says that this is not very kosher (per ANSI standard).
> However, it refers to the ANSI Rationale, which seems to imply that
> this is fine.

The standard does not directly address this case, and it was debated
several times in this newsgroup.  Eventually, Defect Report 51 asked
for an official ruling, which was issued as part of Record of Response 1.
As the comp.lang.c FAQ list says, the ruling said that the struct
hack was not strictly conforming with the standard.

Some of us feel that this ruling was "obviously" in error according to
a suitably language-lawyer-like interpretation of the standard's text,
and that that passage in the Rationale implies that it was also *intended*
for the struct hack to be legal.  A Defect Report (written mostly by me)
calling for the ruling to be reversed has, I understand, been submitted
but not yet ruled on.

It probably isn't worthwhile to rehash the technical arguments on either
side here and now.

> Also, another variation of this trick is to declare tag data to be of
> the maximum size you plan to use and then allocate just as much memory
> as you need (i.e. less than sizeof struct x). Are these tricks legal
> in ANSI C?

Defect Reports 72 and 73 asked a number of questions closely related to
these issues.  They are to be answered in Record of Response 2, which,
the last I heard, was not yet in its final form.  The latest draft of RR2
that I've seen effectively makes the the "under-allocating" technique also
illegal (i.e. not strictly conforming).  However, it also declares illegal
another variant that seems completely unexceptionable to me, so I'll be
surprised if there aren't some changes before the response becomes official.
-- 
Mark Brader   | The lawgiver, of all beings, most owes the law allegiance.
msb@sq.com    | He of all men should behave as though the law compelled him.
SoftQuad Inc. | But it is the universal weakness of mankind that what we are
Toronto       | given to administer we presently imagine we own. --H.G. Wells

My text in this article is in the public domain.