From 4812175189496025141 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,a5e7fc89a8659411 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2003-07-21 09:14:00 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: ark@acm.org (Andrew Koenig) Newsgroups: comp.std.c++ Subject: Re: Voided application of indirection operator to pointer-to-void Date: Mon, 21 Jul 2003 16:14:00 +0000 (UTC) Organization: AT&T Labs Research, Florham Park, NJ Lines: 52 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <5765b025.0307210232.6c571eff@posting.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: mail2news.demon.co.uk 1058804040 11663 10.0.0.1 (21 Jul 2003 16:14:00 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Mon, 21 Jul 2003 16:14:00 +0000 (UTC) X-Received: from mulga.cs.mu.oz.au ([128.250.1.22]) by news.demon.co.uk with esmtp (Exim 4.12) id 19edIV-00031y-00 for mail2news@news.news.demon.net; Mon, 21 Jul 2003 16:13:59 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id CAA08932; Tue, 22 Jul 2003 02:13:55 +1000 (EST) X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Path: comp-std-cpp-robomod!not-for-mail X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Delivered-To: std-c++@ucar.edu X-Newsgroups: comp.std.c++ X-Nntp-Posting-Host: tinker.research.att.com X-User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 X-Spam-Status: No, hits=-5.2 required=5.0 tests=BAYES_10,REFERENCES,USER_AGENT_GNUS_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Xref: archiver1.google.com comp.std.c++:20239 Al> Is this legal C++? Al> void f(void *pv) { *pv; } No. Al> Comeau and g++ both fault it. 5.3.1 says the operand of * must be Al> T* where T is an object type or function type - so not void. A Al> note then says T may be incomplete but that does not contradict Al> the preceding, as long as it's an incomplete object type. This is Al> motivated by binding references to objects of incomplete type. Al> The note explicitly (and redundantly) excludes void. Sounds pretty clear, doesn't it? Al> However, we have another source claiming the code is legal, citing Al> 4.1 as showing an intention to allow (undereferenced) lvalues of Al> incomplete type and deducing that if 5.3.1 forbids this it is an Al> oversight. I think not. Al> It seems to me that 4.1 only implies that lvalues of some Al> incomplete types may exist, and 5.3.1 indicates that those Al> generated by the indirection operator must have an object type. I Al> can believe that the committee might have intended to allow Al> creation of void lvalues, motivated either by orthogonality, or by Al> compatibility with C. But the resulting standard seems neither Al> self-contradictory nor obviously broken, so it is not clear there Al> is a defect here. Right. Once you complete an incomplete type, you can refer to values of that type. But void can never be completed. Al> I think this could still benefit from raising a core language Al> issue - this would be an opportunity to make the construct legal, Al> if that was the original intention. It wasn't. Why do you want to evaluate *pv anyway if you're not going to use the result? -- Andrew Koenig, ark@acm.org --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]