This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: About nested Designated Initializers


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;


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]