Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: Bounds checks.
Message-ID: <11809@smoke.BRL.MIL>
Date: 14 Dec 89 07:28:48 GMT
References: <448@longway.TIC.COM> <450@longway.TIC.COM> <15364@haddock.ima.isc.com> <809@prles2.UUCP> <1989Dec8.161820.24804@jarvis.csri.toronto.edu> <1989Dec11.181631.3864@jarvis.csri.toronto.edu> <465@cpsolv.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 18

In article <465@cpsolv.UUCP> rhg@cpsolv.uucp (Richard H. Gumpertz) writes:
>In article <1989Dec11.181631.3864@jarvis.csri.toronto.edu> norvell@csri.toronto.edu (Theo Norvell) writes:
>>int A[N];
>>&A[N] /* Undefined! */
>I think some special language might be required in 3.3.6 to allow &*
>without undefined results, since this is probably what the committee
>desired anyway.  It would be silly to allow A+N but not &A[N]!

I seem to vaguely recall discussion of this point in some X3J11 meeting,
and it is not clear to me whether or not &A[N] being undefined was
intended or not.  This is another case where an official query should
be sent to X3.

For people who didn't follow the argument, &A[N] is equivalent to &(*(A+(N)))
but *(A+(N)) is a semantic violation.  (A+(N)) is okay, but applying * to
it is not okay.

If this reminds you of the sizeof(((foo*)0)->bar) argument, well...