From: Bruno H. <br...@cl...> - 2004-04-27 20:53:41
|
>Submitter-Id: net >Originator: Bruno Haible >Organization: GNU hackers >Confidential: no >Synopsis: compound literal syntax for POD structs gives parse error >Severity: non-critical >Priority: low >Category: c++ >Class: rejects-legal >Release: 3.4.0 >Environment: System: Linux honolulu.ilog.fr 2.4.21-0.13mdk #1 Fri Mar 14 15:08:06 EST 2003 i686 unknown unknown GNU/Linux Architecture: i686 host: i686-pc-linux-gnu build: i686-pc-linux-gnu target: i686-pc-linux-gnu configured with: ../gcc-3.4.0/configure --prefix=/home/haible/gnu/arch/linuxgcc34 --enable-shared --enable-threads --enable-__cxa_atexit --enable-languages=c,c++,f77,java,objc --enable-nls >Description: PR#12615 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12615) dealt with parsing bugs for compound literal expressions that are used as initializer of a variable. Most of this was fixed in G++ 3.4.0, however there is still one case where g++ gives an unjustified error: when the compound literal expression for a POD struct is used to initialze a variable of a subclass of non- POD type. =============================== bug1.cc ================================== struct object { unsigned long one_o; unsigned int allocstamp; }; struct gcv_object_t { unsigned long one_o; operator object () const; gcv_object_t (object obj); gcv_object_t (); }; void gc_mark (object obj) { object target0 = ((object){one_o: 0, allocstamp: 0}); gcv_object_t target1 = gcv_object_t ((object){one_o: 0, allocstamp: 0}); gcv_object_t target2 = (gcv_object_t) ((object){one_o: 0, allocstamp: 0}); gcv_object_t target3; target3 = ((object){one_o: 0, allocstamp: 0}); gcv_object_t target4 = ((object){one_o: 0, allocstamp: 0}); } ========================================================================== $ g++ -O -c bug1.cc bug1.cc: In function `void gc_mark(object)': bug1.cc:20: Fehler: `target4' must be initialized by constructor, not by `{...}' I think this is a bug because 1. The right hand side of the 'target4' initialization is an expression (the fact that it is allowed as right-hand-side of the 'target3' assignment proves this), 2. The right hand side of the 'target4' initialization, to be parsed as a "initializer-clause" (see [dcl.init]), does not have the syntax of a "{ initializer-list ,opt }", but rather is an "assignment-expression", even a "primary-expression". 3. The right hand side is a valid expression of type 'object', gcv_object_t has a constructor with argument type 'object', and therefore [class.expl.init] paragraph 1 allows the initialization of a gcv_object_t variable with an expression of type 'object'. >How-To-Repeat: See above. >Fix: The syntaxes for target1, target2, target3 provide workarounds. |