[dcl.init.aggr] Aggregate initialization VS padding bits

[frederick-vs-ja]

Full name of submitter (unless configured in github; will be published with the issue): Jiang An

Reference (section label): [dcl.init.aggr]

Link to reflector thread (if any):

Issue description:

Consider the following example:

// assuming that there're padding bytes in A and B, which holds for most implementations

struct A {
  char c;
  int i;
};

struct B {
  B() = default; // making B not an aggregate (since C++20)
  char c;
  int i;
};

void test() {
  auto a1 = A();
  auto a2 = A{};
  auto a3 = A{.c{}};
  auto b1 = B();
  auto b2 = B{};
}

As B is not an aggregate and has an eligible default constructor, b1 and b2 are both zero-initialized first and get their padding bits zeroed (per [dcl.init.list] and [dcl.init.general]). See also CWG694.

a1 is also zero-initialized. However, [dcl.init.list] specifies that aggregate initialization, but not value initialization is performed for a2. In [dcl.init.aggr], there's nothing specifying zero-initializing for the whole class object, which leaves padding bits uninitialized.

Note that in C (since C23, via WG14 N2796), an empty initializer causes padding bits zero-initialized. Perhaps it would be better to adopt such behavior for C++ to improve compatibility with C, and reduce the semantic difference between A() and A{}.

Moreover (beyond the compatibility issue with C), it would be surprising a3 has less zero-initialized contents than a2. So I think it would be better to just perform zero-initialization in all forms of aggregate initialization, although we might need to precisely handle unions.

Suggested resolution:

[safocl]

but not value initialization is performed for a2. In [dcl.init.aggr], there's nothing specifying zero-initializing for the whole class object, which leaves padding bits uninitialized.

This is an advantage of aggregate-initialization in C++, as it eliminates unnecessary steps. However, padding bits can still only be accessed in special ways (within the object representation of objects), and their values ​​are not invariants of the value representation of objects. Therefore, I believe the current behavioral model for aggregate-initialization has only positive effects.

[safocl]

if it is necessary for some purpose to fill the entire object with zeros (including padding bits), anyone can perform clearly additional steps to zero the object representation of the corresponding object.

Additionally, any implementation may provide the ability (via configuration) to automatically zero-fill objects.

[jensmaurer]

Padding bits aren't guaranteed to be stable (they're not part of the value representation).

I'm certainly willing to entertain adding an Annex C entry for the C23 difference regarding initialization with empty braces; please post an example where that actually makes a difference.

Anything more in this area seems to straddle design and would better be handled in a paper to EWG.

[frederick-vs-ja]

IIUC the following example shows the difference.

#include <string.h>

void f() {
  struct S {
    char: 8;
    char _;
  } s = {};

  char c;
  memcpy(&c, &s, 1);
  int n = c; // well-defined in C with n initialized to 0, undefined behavior in C++
}

[safocl]

int n = c; // well-defined in C with n initialized to 0, undefined behavior in C++

I don't think this is undefined behavior in C++.
c has an unspecified value.

[basic.fundamental#note-3]

I apologize - at the moment this may have the behavior described in [basic.indet#example-1] (erroneous behavior)

[frederick-vs-ja]

c has an unspecified value.

Agree. But c is then converted to int. It's also unclear whether the memcpy call sets c to an indeterminate value, though.

Whatever the behavior in C++ is, the value of n doesn't seem guaranteed.

[safocl]

It's also unclear whether the memcpy call sets c to an indeterminate value, though.

I believe that even before C++26 it was not an indeterminate value, but an unspecified value (given the rule that padding bits have exactly this value).

Whatever the behavior in C++ is, the value of n doesn't seem guaranteed.

Yes, I also think that the value of n here is unpredictable within the set of values ​​that the type allows. But I also think it has the same behavior in C.

[safocl]

#include <string.h>

void f() {
struct S {
char: 8;
char _;
} s = {};

char c;
memcpy(&c, &s, 1);
int n = c; // well-defined in C with n initialized to 0, undefined behavior in C++
}

#include <string.h>

bool f() {
  struct S1 {
    char c;
    int i;
  } s1 = {};
  
  struct S2 {
    char c;
    int i;
  } s2 = {};

  assert(sizeof(S1) == sizeof(S2));

  return memcmp(&s1, &s2, sizeof(S1)) == 0; // Is equality guaranteed in C? // Equality is not guaranteed in C++.
}

Perhaps you meant something like this as an illustrative example?

[frederick-vs-ja]

Yeah. Perhaps we can make a more guaranteed example:

#include <string.h>

bool f() {
  struct S {
    char c;
    int i;
  } s = {};

  unsigned char buf[sizeof(S)] = {};

  return memcmp(&s, &buf, sizeof(S)) == 0; // Equality is guaranteed in C but not C++.
}

[jensmaurer]

On that last example: Why do you believe the integer value 0 would be represented as all-zero bytes in its object representation? I don't think that's guaranteed.

[safocl]

#include <string.h>

bool f() {
struct S {
char c;
int i;
} s = {};

unsigned char buf[sizeof(S)] = {};

return memcmp(&s, &buf, sizeof(S)) == 0; // Equality is guaranteed in C but not C++.
}

I think this is also guaranteed in C++:
[basic.types.general#2]
[class.prop#1]
[basic.indet#example-1]

upd. oh, i took that as:

#include <string.h>

bool f() {
  struct S {
    char c;
    int i;
  } s = {};

  unsigned char buf[sizeof(S)] = {};
  memcpy(&buf, &s, sizeof(S));
  return memcmp(&s, &buf, sizeof(S)) == 0; // Equality is guaranteed in C but not C++.
}

[jensmaurer]

@safocl , you're not responding to my concern that "int i = 0" doesn't guarantee the object representation of "i" is made of bytes valued zero.

And basic.types.general p2 doesn't apply because we're not copying the bytes back into the original object. Also, the notion of "value" excludes padding bits.

[frederick-vs-ja]

On that last example: Why do you believe the integer value 0 would be represented as all-zero bytes in its object representation? I don't think that's guaranteed.

Oh. Possibly I mistakenly associated [basic.fundamental] p4 and [basic.fundamental] p5. There're N coefficients determining the integer value and N bits in the value representation, but the relation between coefficients and bit values are missing.

However, such relation is present in C. Per WG14 N3854 6.2.6.2 p1:

1. For unsigned integer types the bits of the object representation shall be divided into two groups: value bits and padding bits. If there are N value bits, each bit shall represent a different power of 2 between 1 and 2^N−1, so that objects of that type shall be capable of representing values from 0 to 2^N−1 using a pure binary representation; this shall be known as the value representation. The values of any padding bits are unspecified. The number of value bits N is called the width of the unsigned integer type.

---

[basic.types.general#2]
[class.prop#1]
[basic.indet#example-1]

Hmm... I don't think these apply to examples using memcmp, as we don't copy object/value representation.

[safocl]

@safocl , you're not responding to my concern that "int i = 0" doesn't guarantee the object representation of "i" is made of bytes valued zero.

I didn't understand your question. Could you clarify which statement or assumption of mine you're referring to?

Before your initial message (#issuecomment-4619893748) on this matter, I stated, on the contrary, that at least in C++, equality of object representations of objects containing padding bits is not guaranteed (#912 (comment)).