Fun fact: GCC decided to adopt Clang's (old) behavior at the same time Clang decided to adopt GCC's (old) behavior.

So now you have this matrix of behaviors: * Old GCC: Initializes whole union. * New GCC: Initializes first member only. * Old Clang: Initializes first member only. * New Clang: Initializes whole union.

▲

augusto-moura 8 months ago | parent | next [-]

That's funny and sad at the same time.

And it shows a deeper problem, even though they are willing to align behavior between each other, they failed to communicate and discuss what would be the best approach. That's a bit tragic, IMO

▲

Neywiny 8 months ago | parent [-]

I would argue the even deeper problem is that it's implementation defined. Should be in the spec and they should conform to the spec. That's why I'm so paranoid and zeroize things myself. Too much hassle to remember what is or isn't zero.

▲

flohofwoe 8 months ago | parent [-]

I wouldn't depend on that too much either though, or at least not depend on padding bytes being zeroed. The compiler is free to replace the memset call with code that only zeroes the struct members, but leaves junk in the padding bytes (and the same is true when copying/assigning a struct).

	▲	Gibbon1 8 months ago \| parent [-]
		Standard should be changed to require all uninitialized memory be set to zero. Which includes padding bytes.

▲

homebrewer 8 months ago | parent | prev | next [-]

Since having multiple compilers is often touted as an advantage, how often do situations like what you're describing happen compared to the opposite — when a second compiler surfaces bugs in one's application or the other compiler?

	▲	uecker 8 months ago \| parent [-]
		I compile my projects with clang and GCC. It is quite often that one compilers finds minor issues the other does not.

▲

iamthejuan 8 months ago | parent | prev | next [-]

It is like an era of average.

▲

zeroq 8 months ago | parent | prev [-]

i will call it "webification" of C!