Bug 10676 - Using unnamed fields in initializers
Summary: Using unnamed fields in initializers
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 3.2.2
: P3 minor
Target Milestone: 4.6.0
Assignee: Not yet assigned to anyone
URL:
Keywords: rejects-valid
: 14094 24065 30737 38019 40656 42875 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-05-08 02:26 UTC by marcus
Modified: 2010-05-15 03:23 UTC (History)
13 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.6.0
Known to fail: 4.5.0
Last reconfirmed: 2010-04-26 18:33:15


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description marcus 2003-05-08 02:26:00 UTC
union
{
  int raw;
  struct
  {
    int foo;
  };
} baz = { .raw = 0 },   /* OK */
  zab = { .foo = 1 };   /* unknown field `foo' specified in initializer */

Unnamed unions/structs are very useful.  If the initializer for zab were valid, they would be even more useful.

Thanks for your consideration,
Marcus

Release:
gcc (GCC) 3.2.2 20030124 (Debian prerelease)

Environment:
Debian GNU/Linux i386-linux-gnu
Comment 1 Andrew Pinski 2003-05-31 14:12:18 UTC
Happens on the mainline (20030531), 3.3.1 (20030526), 3.2.3, and 3.0.4:

tin:~/src/gnu/gcctest>gcc pr10676.c 
pr10676.c:9: error: unknown field `foo' specified in initializer
tin:~/src/gnu/gcctest>~/ia32_linux_gcc3_2/bin/gcc pr10676.c
pr10676.c:9: unknown field `foo' specified in initializer
tin:~/src/gnu/gcctest>~/ia32_linux_gcc3_3/bin/gcc pr10676.c
pr10676.c:9: error: unknown field `foo' specified in initializer
tin:~/src/gnu/gcctest>~/ia32_linux_gcc3_0/bin/gcc pr10676.c
pr10676.c:9: unknown field `foo' specified in initializer
Comment 2 Andrew Pinski 2004-02-10 11:16:02 UTC
*** Bug 14094 has been marked as a duplicate of this bug. ***
Comment 3 Johan Rydberg 2005-02-15 18:30:25 UTC
Still happens on 4.0 snapshot of 20050213 :

$ /gnu/bin/gcc -c pr10676.c
pr10676.c:9: error: unknown field 'foo' specified in initializer
$ /gnu/bin/gcc -v
...
gcc version 4.0.0 20050213 (experimental)
Comment 4 Joseph S. Myers 2005-09-26 12:15:45 UTC
*** Bug 24065 has been marked as a duplicate of this bug. ***
Comment 5 Andrew Pinski 2007-02-09 18:43:51 UTC
*** Bug 30737 has been marked as a duplicate of this bug. ***
Comment 6 Josh Triplett 2008-11-05 17:19:07 UTC
*** Bug 38019 has been marked as a duplicate of this bug. ***
Comment 7 Josh Triplett 2008-11-05 17:20:22 UTC
Still happens with GCC 4.3.2:

$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1) 
Comment 8 Josh Triplett 2008-11-05 17:21:59 UTC
How can I update the "last confirmed" date to today?
Comment 9 Jonathan Brandmeyer 2009-06-17 17:16:25 UTC
Similarly, I would like the following to work as an extension to the anonymous union support:

Given a structure like:
     struct foo {
       int a;
       union {
         int b;
         float c;
       };
       int d;
     };

I want to initialize it with a statement like:
struct foo value_of_foo = { .a = 0, .b = 1, .d = 2 };

instead of what is currently required, with braces around the initialization of 'foo::b':
struct foo value_of_foo = { .a = 0, { .b = 1 }, .d = 2 };

This is a natural extension of the ability to access members 'b' and 'c' without tagging their union type.
Comment 10 Andrew Pinski 2009-07-06 19:30:49 UTC
*** Bug 40656 has been marked as a duplicate of this bug. ***
Comment 11 Jan Cornelis 2009-08-27 14:57:57 UTC
An example program that shows 3 different methods. Only one works (see comment) 
As I used the names for each field, I assumed that all 3 examples should work. 

#include <inttypes.h>
#include <stdio.h>

struct a_t {
  uint16_t a;
  uint16_t b;
  union {
      uint8_t c;
    uint16_t d;
  };
};

#if (1)
struct a_t alfa = {
  .a = 1,
  .b = 2,
  .c = 3, //Will not work
};
#elif (0)
struct a_t alfa = {
  .a = 1,
  .b = 2,
  {.c = 3}, //works
};
#elif (0)
struct a_t alfa = {
  .a = 1,
  {.c= 2}, //Does not work
  .b = 3,
}
#endif

int main(void)
{
  //alfa.c = 4;
  //alfa.d = 5;
  printf("%20s:%d\n","alfa.a",alfa.a);
  printf("%20s:%d\n","alfa.b",alfa.b);
  printf("%20s:%d\n","alfa.c",alfa.c);
  printf("%20s:%d\n","alfa.d",alfa.d);
 return 0; 
}
Comment 12 Mat Hostetter 2010-01-26 16:25:54 UTC
*** Bug 42875 has been marked as a duplicate of this bug. ***
Comment 13 Mat Hostetter 2010-01-26 16:28:24 UTC
This "bug" is causing me difficulty porting from an EDG-based compiler to gcc-4.4.3.  EDG implemented "assignment" and "initialization" as having the same namespace.
Comment 14 Joseph S. Myers 2010-01-26 16:32:30 UTC
C1x anonymous structures and unions will likely require a fix for this.
Comment 15 Joseph S. Myers 2010-05-09 20:39:53 UTC
Subject: Bug 10676

Author: jsm28
Date: Sun May  9 20:39:39 2010
New Revision: 159206

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159206
Log:
	PR c/10676
	* c-typeck.c (lookup_field): Take a type directly.  Update
	recursive calls.
	(build_component_ref): Update call to lookup_field.
	(set_init_label): Use lookup_field to find initialized field.
	Handle returned list of fields like a sequence of designators.

testsuite:
	* gcc.dg/anon-struct-10.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/anon-struct-10.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/c-typeck.c
    trunk/gcc/testsuite/ChangeLog

Comment 16 Joseph S. Myers 2010-05-09 20:42:19 UTC
Fixed for 4.6.
Comment 17 Dave Korn 2010-05-09 21:00:11 UTC
Thank you!
Comment 18 Andrzej Zaborowski 2010-05-15 03:23:40 UTC
(In reply to comment #11)
> An example program that shows 3 different methods. Only one works (see comment) 
>   .c = 3, //Will not work
>   {.c = 3}, //works
>   {.c= 2}, //Does not work

For sake of documentation, with versions from before the fix the second method did not always work.  It seems to depend also on the ordering of the members in the anonymous union.  If .c is the first, second or third member of the union it seems to work.  It does not work for the fourth and following members.  Really puzzling.