karl@haddock.ima.isc.com (Karl Heuer) (10/09/90)
In article <14049@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > int a[4][5]; > a[1][7] = 0; /* undefined behavior */ >[justification for the above] I presume that this ruling (if upheld) also means that strictly conforming programs may not use extensible structs via the usual overmalloc hack? >What is missing in the standard that would be required for such punning >to be strictly conforming is some sort of guarantee that an array of >arrays of T is also in some contexts considered an array of T itself. I believe X3J11 has previously stated that "objects are composed of bytes" means that any object may be considered an array of char. If this continues to be true, and yet the above example is illegal, then there's a bunch of intermediate cases that have questionable legality. I posted an article about this (my "proof" that extensible structs are legal) on or around 20-Dec-1989, I think. Anyone still have a copy? Karl W. Z. Heuer (karl@kelp.ima.isc.com or ima!kelp!karl), The Walking Lint
flaps@dgp.toronto.edu (Alan J Rosenthal) (10/09/90)
karl@haddock.ima.isc.com (Karl Heuer) writes: >In article <14049@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >> int a[4][5]; >> a[1][7] = 0; /* undefined behavior */ > >I presume that this ruling (if upheld) also means that strictly conforming >programs may not use extensible structs via the usual overmalloc hack? Alternatively, (int (*)[5])malloc(4 * 5 * sizeof(int)) may be deemed to create an object viewable as being 20 ints even though int a[4][5] does not, in which case the overmalloc hack would still be fine (though blecherous). ajr -- "Anytime there are electronic systems there are usually complications of electronic failure," he said.