On 20 July 2011 00:45, Cheng Renquan wrote:
> On Tue, Jul 19, 2011 at 4:18 PM, Jonathan Wakely <jwakely....@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.
