This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: About nested Designated Initializers
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 (çäå)