Does C++ standard guarantee the initialization of padding bytes to zero for non-static aggregate objects?

Question

Does C++ support any language construct that will allow us to initialize an object and all its padding fields to zero. I found some encouraging wording in cppreference.com about zero-initialization that suggests that on some conditions, the padding bytes will also be zeroed out.

Quoting from cppreference.com: zero-initialization

Zero initialization is performed in the following situations:

2. As part of value-initialization sequence for non-class types and for members of value-initialized class types that have no constructors, including value initialization of elements of aggregates for which no initializers are provided.

The effects of zero initialization are:

• If T is a scalar type, the object's initial value is the integral constant zero explicitly converted to T.
• If T is an non-union class type, all base classes and non-static data members are zero-initialized, and all padding is initialized to zero bits. The constructors, if any, are ignored.
• ...

One will find references to zero-initialization invalue-initialization , aggregate-initialization and list-initialization .

I tested out the fairly latest g++ and clang++, and their behavior seems divergent.

Frankly, I tried hard to parse these rules, especially given that the divergent compiler behavior, I could not figure out how to interpret these rules correctly.

See code here . And here are the results:

Given: Foo

struct Foo
{
    char x;
    int y;
    char z;
};

Constuct	g++	clang++
Foo()	x = [----] [0x42] [0x43] [0x44], v = 0	x = [----] [----] [----] [----], v = 0
	y = [----] [----] [----] [----], v = 0	y = [----] [----] [----] [----], v = 0
	z = [----] [0x4A] [0x4B] [0x4C], v = 0	z = [----] [----] [----] [----], v = 0
Foo{}	x = [----] [----] [----] [----], v = 0	x = [----] [0x42] [0x43] [0x44], v = 0
	y = [----] [----] [----] [----], v = 0	y = [----] [----] [----] [----], v = 0
	z = [----] [----] [----] [----], v = 0	z = [----] [0x4A] [0x4B] [0x4C], v = 0

Here [----] represents a byte containing all bits 0, and [0x..] is garbage value.

As you can see the compiler outputs indicate that padding is not initialized. Both Foo() and Foo{} are value-initializations. In addition Foo{} is an aggregate-initialization, with missing initializers. Why isn't the zero-initialization rule getting triggered? Why isn't padding rule getting triggered?

I already understand that relying on padding bytes to be zero is not a good idea or may even be undefined behavior, but I think that is besides the point of this question.

• Question 1: Is my interpretation of these rules wrong. Are so my expectations?
• Question 1: Does the standard provide a way to reliably initialize the padding bytes?
• Question 2: Are these compilers compliant with the standards?
• Question 3: What is the explanation of the compiler's clearly divergent behavior?

Answer 1

The padding bits will be zeroed only if the class object is zero-initialized, as expressed in your quote.

For automatic storage duration objects zero-initialization happens only if the object is value-initialized and it has a non-deleted implicit default constructor and no other user-provided default constructor. [dcl.init.general]/8.1 These conditions are fulfilled here.

Value-initialization should always happen with the () initializer. ([dcl.init.general]/16.4 )

Value-initialization could also happen for {} as initializer. However, if the class is an aggregate as it is here, aggregate-initialization is preferred, which doesn't result in value-initialization. ( [dcl.init.list]/3.4 )

The preference of aggregate-initialization over value-initialization was changed by CWG 1301 before C++14.

---

So I would say GCC is wrong on Foo() and is doing unnecessary work for Foo{} . Clang seems to behave correctly.

Answer 2

1. They are probably wrong.

2. No. The padding is always added by you. 16-byte aligned matrices and vectors are usualy padded in directx applications, and they MUST be aligned/padded by the developer, as for example, shaders will fail badly. Simply saying, you will get wrong data at input of vertex shader.

3. no idea.

4. no idea.

C++ is low level and never guaranteed any zeros nor padding zeros. Wake up. Let low level be low level. In directX feature level 12_0 it even became more significant. Spit! Spit! Spit!