Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!ames!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: address of function
Message-ID: <10410@smoke.BRL.MIL>
Date: 16 Jun 89 21:37:44 GMT
References: <2700@solo8.cs.vu.nl> <370@msor0.UUCP> <1817@auspex.auspex.com> <10361@socslgw.csl.sony.JUNET>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 19

In article <10361@socslgw.csl.sony.JUNET> diamond@csl.sony.junet (Norman Diamond) writes:
>>> ... and does ANSI permit the following ?
>>>	int	this[100], *that = &this;
>In article <1817@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>>No.  It does permit
>>	int	this[100], (*that)[100] = &this;
>Oh I'm so glad ANSI is standardizing existing practices instead of
>inventing new RESTRICTIONS.  This rule won't break much existing,
>FORMERLY UNBROKEN source code, now will it?  :-S  (sarcasm)

The (proposed) Standard does not in this regard (&array_name) break
existing correct code.  The base document, K&R1 Appendix A, quite
clearly constrains & to be applied to an lvalue and states that an
array identifier is not an lvalue expression.  The Standard has
actually extended the language in this regard, not restricted it.

The fact that some old compilers were sloppy and permitted an & to
be applied to an array identifier (usually as a no-op) is irrelevant
since it was not something a programmer could legitimately rely on.