From -1407263647726099060 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,8366734ec6aad121 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1994-06-19 00:18:09 PST Newsgroups: comp.std.c++ Path: nntp.gmd.de!xlink.net!howland.reston.ans.net!swrinde!ihnp4.ucsd.edu!munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!fjh From: fjh@munta.cs.mu.OZ.AU (Fergus Henderson) Subject: Re: new foo[0] Message-ID: <9417017.29003@mulga.cs.mu.OZ.AU> Sender: news@cs.mu.OZ.AU Organization: Computer Science, University of Melbourne, Australia References: <9415818.9649@mulga.cs.mu.OZ.AU> <9417005.12163@mulga.cs.mu.OZ.AU> Date: Sun, 19 Jun 1994 07:16:24 GMT Lines: 20 jason@cygnus.com (Jason Merrill) writes: >>>>>> Fergus Henderson writes: > >> I do think that it's use as the operand of `unary &' should be allowed. > >I think that this falls into the provisions of [expr.add], since this >expression is equivalent to &(*(myfoo0+0)). This section says basically >that evaluating a pointer arithmetic expression which points one past the >end of an array is allowed, but using that expression as the operand of the >unary * operator yields undefined behavior. A strict reading would >indicate that the behavior of &myfoo[0] is thus undefined, but I suspect >that [expr.add] only meant to deal with actual dereferences. Yes, the working paper is incorrect here, IMHO. But that also raises the question of the legality of `&*foo'. Here there is no addition involved, so that section doesn't apply. -- Fergus Henderson - fjh@munta.cs.mu.oz.au