C gore of the weak

1. Does this operation invoke undefined behavior?

union {
  int i;
  struct {
    int i1;
    int i2;
  } s;
} u;

u.i = 3;
printf("%d\n", u.s.i1);

It won't even compile like that!

AFAIK, the compiler can insert padding wherever it feels like it, so it won't necessarily work. Or maybe that's just Sepples.

I'm going to say yes which means the answer is going to be no :(

That style is pig disgusting.
I'm sorry, I can't read that.

>>5
Happy, you smelly GNU hippo?
union
 {
  int i;
  struct
   {
    int i1;
    int i2;
   } s;
 } u;

>>6
Thank you dear sir, I came.

>>5
>>1-san's code is fine.

>>1
Yes, that will produce undefined behavior in the strictest sense, but may be perfectly fine in practice, especially if you don't need to concern yourself over the details of platform changes.

After reading C99 6.7.2.1 #13 and #14, I think it will print 3 and not summon nasal demons, even on the DS9K.

>>9
Correct.

chrisdesktop:prog christopher$ cat union.c | gcc -o lol -xc - && ./lol
3
chrisdesktop:prog christopher$ █

>>11
I think you mean cat union.c | cat | cat | cat | cat | cat | cat | cat | gcc -o lol -xc - && ./lol

>using unions in 2009

unions 2012
for a better america

>>13
>I've never coded for anything that doesn't have 4gb of available memory.

I think compilers should reorder structs in reverse member size order (largest members first) to minimize padding waste. Elements with the same size would be placed in declaration order. What could possibly go wrong with such a scheme? It wouldn't affect >>1 but it might break more unorthodox uses (which I'm sure are undefined behavior to begin with).

>>16
What could possibly go wrong
Back to /slashdot/, plea--
scheme
Oh, carry on then!

It invokes UB most certainly.

>>18
Really!?  >>9 looked it up and found that there is no padding in the beginning of a struct, which means that the two variables will have the same memory location, i.e. no undefined memory will be read.

>>16
I don't remember the details, but IIRC the standard allows arbitrary between-elements padding (A fact which x86 only programmers seem to be gaily oblivious of, going by the broken code they churn out), but disallows any reordering of struct elements. I suppose it could affect the outcome of some unlikely pointer comparisons, and 'creative' reuse of the end of a struct as storage if there are occasionally unneeded fields.
Certainly you wouldn't want to relocate any flexible array members, but that would be pointless anyway.
-fipa-struct-reorg can do some funky stuff with structures, but the primary goal is to increase loop locality, not to eliminate padding.

>>19
The UB is that you read the value of a member you haven't written to previously, and has nothing to do with struct representation.
It's true that (void *)s == (void *)&s->first_member, but irrelevant.

>>20
but disallows any reordering of struct elements.
Correct. The offsetof macro would be useless without this guarantee.

>>21
Type punning through unions is allowed since C99 TC3, per http://www.open-std.org/JTC1/SC22/wg14/www/docs/dr_283.htm .

>>21
Correct. The offsetof macro would be useless without this guarantee.
How so? Assuming it was consistent, you would still be able to access a field using a pointer to a struct + the member's offsetof.
Are you using for some kind of sizeof calculation?