Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!kddlab!titcca!sragwa!wsgw!socslgw!diamond!diamond
From: diamond@diamond.csl.sony.junet (Norman Diamond)
Newsgroups: comp.lang.c
Subject: Re: address of function
Message-ID: <10361@socslgw.csl.sony.JUNET>
Date: 14 Jun 89 04:06:20 GMT
References: <2700@solo8.cs.vu.nl> <370@msor0.UUCP> <1817@auspex.auspex.com>
Sender: news@csl.sony.JUNET
Reply-To: diamond@csl.sony.junet (Norman Diamond)
Organization: Sony Computer Science Laboratory Inc., Tokyo, Japan
Lines: 29

in answer to someone's question:

>> ... 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;
>since "&this" is a pointer to "this", and "this" is an array of 100
>"int"s, so "&this" is a pointer to an array of 100 "int"s (not a pointer
>to a single "int"

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)

Could one also do it in this way?
	int	this[100], *that = (int *)&this;
or maybe in this way?
	int	this[100], *that = (void *)&this;

i.e.:  when a cast implies an assignment to an anonymous temporary, it
becomes a non-lvalue -- ok; but does it also become a non-constant?

--
Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.co.jp@relay.cs.net)
 The above opinions are my own.  However, if you see this at Waterloo, Stanford,
 or Anterior, then their administrators must have approved of these opinions.