Path: utzoo!attcan!uunet!world!decwrl!shelby!rutgers!news-server.csri.toronto.edu!dgp.toronto.edu!flaps
From: flaps@dgp.toronto.edu (Alan J Rosenthal)
Newsgroups: comp.std.c
Subject: Re: bounds checking (was: X3J11 Pleasanton meeting summary)
Message-ID: <1990Oct9.101243.28086@jarvis.csri.toronto.edu>
Date: 9 Oct 90 14:12:44 GMT
References: <13996@smoke.BRL.MIL> <1990Oct3.184359.2348@sq.sq.com> <1737:Oct803:02:5890@kramden.acf.nyu.edu> <14049@smoke.BRL.MIL> <18456@haddock.ima.isc.com>
Lines: 18

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.