About nested Designated Initializers

About nested Designated Initializers

[Cheng Renquan]

Hi all,

From info gcc I know it accepts a series of `.FIELDNAME' and `[INDEX]'
designators,
like

     struct point ptarray[10] = { [2].y = yv2, [2].x = xv2, [0].x = xv0 };


But in my case, I have a struct with array of int as members,

     struct mbox {
       int x[20];
       int y[20];
     };

and want to declare a mbox variable with partially initialized, like

     struct mbox mbox = { .x = { 1, 2 }, .y[19] = 3, };

During compiling, I see warnings, and the compiled program doesn't
work like what I think,

slfe.c:823: warning: braces around scalar initializer
slfe.c:823: warning: (near initialization for `mbox.s[2]')
slfe.c:825: warning: passing arg 1 of `hexdump' from incompatible pointer type


Then I use a hexdump on this var, found it's working like

 struct mbox mbox = { .x = { 1, 2 }, .y = 3, };

I wonder if this is gcc bug, or if gcc doesn't support this kind of
designated initializer,

But if this is supported,
     struct point ptarray[10] = { [2].y = yv2, [2].x = xv2, [0].x = xv0 };

Why can't we support this?
     struct mbox mbox = { .x = { 1, 2 }, .y[19] = 3, };

Or someone knows which standard (like C99?) has related spec?

Thanks,


5.20 Designated Initializers
============================

Standard C89 requires the elements of an initializer to appear in a
fixed order, the same as the order of the elements in the array or
structure being initialized.


 You can also write a series of `.FIELDNAME' and `[INDEX]' designators
before an `=' to specify a nested subobject to initialize; the list is
taken relative to the subobject corresponding to the closest
surrounding brace pair.  For example, with the `struct point'
declaration above:

     struct point ptarray[10] = { [2].y = yv2, [2].x = xv2, [0].x = xv0 };



--
Cheng Renquan (程任全)

Re: About nested Designated Initializers

[Cheng Renquan]

On Tue, Jul 19, 2011 at 2:56 PM, Cheng Renquan <crquan@gmail.com> wrote:
> Hi all,
>
> From info gcc I know it accepts a series of `.FIELDNAME' and `[INDEX]'
> designators,
> like
>
>     struct point ptarray[10] = { [2].y = yv2, [2].x = xv2, [0].x = xv0 };
>
>
> But in my case, I have a struct with array of int as members,
>
>     struct mbox {
>       int x[20];
>       int y[20];
>     };
>
> and want to declare a mbox variable with partially initialized, like
>
>     struct mbox mbox = { .x = { 1, 2 }, .y[19] = 3, };

Sorry, my above example is not good, it compiles and works ok;

What's really not working is this example by union:

      union mbox {
          int   w[3];
          short s[6];
          char  c[12];
      };

If I declare a union mbox and want to initialize w[0], s[2] and c[6],

  union mbox mbox = { .w = { 1, }, .s[2] = 2, .c[6] = 's' };

I want a mbox initialized with these 12 bytes (on little endian):

0000:   01 00 00 00 02 00 73 00  00 00 00 00

And actually I got these:

0000:   00 00 00 00 00 00 73 00  00 00 00 00

the hexdump result shows only last .c[6] make effect,

Wonder if this is a bug or not supported? Thanks,

Re: About nested Designated Initializers

[Jonathan Wakely]

On 19 July 2011 23:57, Cheng Renquan wrote:
> On Tue, Jul 19, 2011 at 2:56 PM, Cheng Renquan <crquan@gmail.com> wrote:
>> Hi all,
>>
>> From info gcc I know it accepts a series of `.FIELDNAME' and `[INDEX]'
>> designators,
>> like
>>
>>     struct point ptarray[10] = { [2].y = yv2, [2].x = xv2, [0].x = xv0 };
>>
>>
>> But in my case, I have a struct with array of int as members,
>>
>>     struct mbox {
>>       int x[20];
>>       int y[20];
>>     };
>>
>> and want to declare a mbox variable with partially initialized, like
>>
>>     struct mbox mbox = { .x = { 1, 2 }, .y[19] = 3, };
>
> Sorry, my above example is not good, it compiles and works ok;
>
> What's really not working is this example by union:
>
>      union mbox {
>          int   w[3];
>          short s[6];
>          char  c[12];
>      };
>
> If I declare a union mbox and want to initialize w[0], s[2] and c[6],
>
>  union mbox mbox = { .w = { 1, }, .s[2] = 2, .c[6] = 's' };
>
> I want a mbox initialized with these 12 bytes (on little endian):
>
> 0000:   01 00 00 00 02 00 73 00  00 00 00 00
>
> And actually I got these:
>
> 0000:   00 00 00 00 00 00 73 00  00 00 00 00
>
> the hexdump result shows only last .c[6] make effect,
>
> Wonder if this is a bug or not supported? Thanks,
>

This question is more suitable for the gcc-help list, as it is a
question about using gcc not about developing it.

What you want is not supported.  The member of the union that is
initialized will either be the int[3], or the short[6], or the
char[12].  You cannot initialize some bytes of one member and some
bytes of another like that.

Maybe you should just do this instead:

union mbox mbox = { .c[0] = 1, .c[4] = 2, .c[6] = 's' };

Re: About nested Designated Initializers

[Cheng Renquan]

On Tue, Jul 19, 2011 at 4:18 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> This question is more suitable for the gcc-help list, as it is a
> question about using gcc not about developing it.

What I insist to discuss here is I think this may be a gcc's bug,
could be fixed in some future day?

>
> What you want is not supported.  The member of the union that is
> initialized will either be the int[3], or the short[6], or the
> char[12].  You cannot initialize some bytes of one member and some
> bytes of another like that.

Do you know why is it not supported? Is there some standard (like
C99?) forbid to
implement it?

Otherwise we could see it as a gcc bug;

>
> Maybe you should just do this instead:
>
> union mbox mbox = { .c[0] = 1, .c[4] = 2, .c[6] = 's' };

Sorry, my above still not a good example, what I mean to initialize is
.w[0] is a real 4 bytes integer, .s[2] is real short, those are not
convenient to write in .c[...];

like this example:

  union mbox mbox = { .w[0] = 0x12345678, .s[2] = 0xabcd, .c[6] = 's' };

I tried hexdump again, only last one .c[6] was initialized,

I think to initialize .w[0] / .s[2] / .c[6] have no conflict with each
other, why can't we implement such behavior?


Thanks;

Re: About nested Designated Initializers

[Jonathan Wakely]

On 20 July 2011 00:45, Cheng Renquan wrote:
> On Tue, Jul 19, 2011 at 4:18 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>> This question is more suitable for the gcc-help list, as it is a
>> question about using gcc not about developing it.
>
> What I insist to discuss here is I think this may be a gcc's bug,

This isn't the right list for that either.  Questions about using gcc
should go to gcc-help, bug reports should go to bugzilla.

> could be fixed in some future day?

It's not a bug, it's how unions work.

>> What you want is not supported.  The member of the union that is
>> initialized will either be the int[3], or the short[6], or the
>> char[12].  You cannot initialize some bytes of one member and some
>> bytes of another like that.
>
> Do you know why is it not supported? Is there some standard (like
> C99?) forbid to
> implement it?

C99 doesn't even support .c[6] syntax for initializers, it's a GCC extension.

> Otherwise we could see it as a gcc bug;

I don't think so.

>>
>> Maybe you should just do this instead:
>>
>> union mbox mbox = { .c[0] = 1, .c[4] = 2, .c[6] = 's' };
>
> Sorry, my above still not a good example, what I mean to initialize is
> .w[0] is a real 4 bytes integer, .s[2] is real short, those are not
> convenient to write in .c[...];
>
> like this example:
>
>  union mbox mbox = { .w[0] = 0x12345678, .s[2] = 0xabcd, .c[6] = 's' };
>
> I tried hexdump again, only last one .c[6] was initialized,
>
> I think to initialize .w[0] / .s[2] / .c[6] have no conflict with each
> other, why can't we implement such behavior?

Because only one union member can be initialized, and the union
members are w, s, and c, not w[0] etc.

If you want finer-grained control of sub-objects of the union members
then set the elements later via assignment, instead of trying to do it
via initialization.

Re: About nested Designated Initializers

[Cheng Renquan]

On Tue, Jul 19, 2011 at 5:04 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> This isn't the right list for that either.  Questions about using gcc
> should go to gcc-help, bug reports should go to bugzilla.

I know how to use current gcc implementation correctly, I'm thinking
of a new feature in future gcc version, shouldn't we discuss potential
ideas of gcc on this list?

>
>> could be fixed in some future day?
>
> It's not a bug, it's how unions work.

So if not a bug, it should not go to bugzilla?

>
>>> What you want is not supported.  The member of the union that is
>>> initialized will either be the int[3], or the short[6], or the
>>> char[12].  You cannot initialize some bytes of one member and some
>>> bytes of another like that.
>>
>> Do you know why is it not supported? Is there some standard (like
>> C99?) forbid to
>> implement it?
>
> C99 doesn't even support .c[6] syntax for initializers, it's a GCC extension.
>
>> Otherwise we could see it as a gcc bug;
>
> I don't think so.
>
>>>
>>> Maybe you should just do this instead:
>>>
>>> union mbox mbox = { .c[0] = 1, .c[4] = 2, .c[6] = 's' };
>>
>> Sorry, my above still not a good example, what I mean to initialize is
>> .w[0] is a real 4 bytes integer, .s[2] is real short, those are not
>> convenient to write in .c[...];
>>
>> like this example:
>>
>>  union mbox mbox = { .w[0] = 0x12345678, .s[2] = 0xabcd, .c[6] = 's' };
>>
>> I tried hexdump again, only last one .c[6] was initialized,
>>
>> I think to initialize .w[0] / .s[2] / .c[6] have no conflict with each
>> other, why can't we implement such behavior?
>
> Because only one union member can be initialized, and the union

Who (or what standard) defined that behavior?
Can we implement a new behavior as a new GCC extension when there is
no conflict?
(or futhermore, we could detect potential conflicts and prompt the
user with warnings)

    union mbox mbox = { .w[0] = 0x12345678, .s[2] = 0xabcd, .c[6] = 's' };

as same semantic of:

    union mbox mbox;
    mbox.w[0] = 0x12345678;
    mbox.s[2] = 0xabcd;
    mbox.c[6] = 's';

It saves #LOC, looks straightforward and cool, isn't it?

From technology perspective, I didn't see any reasons preventing us
from implementing it,



Or at least, if you insist the syntax,
should we at least give some warnings because it didn't work as I
expected before;
(to warn the user that .w and .s initializers doesn't effect?)

    union mbox mbox = { .w[0] = 0x12345678, .s[2] = 0xabcd, .c[6] = 's' };



> members are w, s, and c, not w[0] etc.

>
> If you want finer-grained control of sub-objects of the union members
> then set the elements later via assignment, instead of trying to do it
> via initialization.

I know that way in above code already,

-- 
Cheng Renquan (程任全)

Re: About nested Designated Initializers

[Jonathan Wakely]

On 20 July 2011 01:04, Jonathan Wakely wrote:
>
> C99 doesn't even support .c[6] syntax for initializers, it's a GCC extension.

Apologies, C99 does support that, my mistake.

But you can still only initialize one member of a union.