C, C11 and later: padding not set to “zero bits” in compound literal

[pascal-cuoq]

Consider the C program:

#include <stdint.h>
#include <string.h>
#include <stdio.h>

struct record {
  uint64_t id;
  uint32_t gold_coins;
};

__attribute__((noinline))
void sink(void*p) {
    static const struct record ref = {1};
    if (memcmp(&ref, p, sizeof ref))
      printf("different\n");
    else
      printf("identical\n");
}

int main(void) {
    struct record a = {1};
    sink(&a);

    void *p = &(struct record){1};
    sink(p);
}

The program above compiled with Clang 15.0.0 using clang -std=c17 -O2 prints:

identical
different

Compiler Explorer link

The “different” output shows that the padding of the compound literal was not set to 0. Here's the relevant snippet of the generated assembly:

        movq    $1, (%rsp)
        movl    $0, 8(%rsp)
        movq    %rsp, %rdi
        callq   sink

This might indicate a bug in Clang, depending on how one interprets the words “the remainder of the aggregate” in C17 6.7.9:21:

If there are fewer initializers in a brace-enclosed list than there are elements or members of an aggregate, or fewer characters in a string literal used to initialize an array of known size than there are elements in the array, the remainder of the aggregate shall be initialized implicitly the same as objects that have static storage duration.

If “the remainder of the aggregate” is taken to include padding, then the padding should be zeroed in the compound literal in my example according to C17 6.7.9:10, which applies in this case per the phrase “the same as objects that have static storage duration” in 6.7.9:21.

If “the remainder of the aggregate” is taken not to include padding, then Clang needlessly generates and copies zero bits in the case of the automatic variable a. From the assembly output:

.L__const.main.a:
        .quad   1                               # 0x1
        .long   0                               # 0x0
        .zero   4

[llvmbot]

@llvm/issue-subscribers-c17

[llvmbot]

@llvm/issue-subscribers-c11

[pascal-cuoq]

In a private discussion, Alexander Monakov has brought to my attention the fact that in my first example, the fact that the padding of automatic variable a is initialized is accidental to the way I wrote the test.

In his modified example, no compound literal is needed. Additionally, MSan reports the use of uninitialized memory:

Commandline: clang -std=c17 -O2 -fsanitize=memory, Compiler Explorer link

#include <stdint.h>
#include <string.h>
#include <stdio.h>

struct record {
  uint32_t gold_coins;
  uint64_t id;
};

__attribute__((noinline))
void sink(void*p) {
    static const struct record ref = {1};
    if (memcmp(&ref, p, sizeof ref))
      fprintf(stderr, "different\n");
    else
      fprintf(stderr, "identical\n");
}

int main(int argc, char **argv) {
    struct record a = {1 + argc - argc};
    sink(&a);
}

In conclusion, but it would be nice to have official confirmation of this, it appears that Clang's interpretation is already that padding needn't be initialized to zero when the phrase “the remainder of the aggregate shall be initialized implicitly the same as objects that have static storage duration” applies to a struct, for all kinds of automatic structs.

[AaronBallman]

CC @efriedma-quic and @rjmccall -- as best I can tell, this seems to be a codegen issue in EmitAutoVarInit() or thereabouts. My reading of https://cigix.me/c17#6.7.9.p21 is that the padding bits are part of the remainder of the object and should be initialized. That's based on my belief that the intent of that rule is to make the following code behave deterministically:

struct S {
  char c;
  int i;
};

int main(void) {
  struct S s1 = { 0 }; // Common init pattern for "please zero init everything"
  static struct S s2;
  return memcmp(&s1, &s2, sizeof(struct S)) == 0;
}

WDYT?

[nikic]

The way that clang interprets the spec wording is that only remaining members/subobjects need to be initialized according to static storage duration initialization. That means that padding will only be initialized if it is part of a remaining subobject.

[rjmccall]

Interpreting "the remainder of the aggregate" as including padding would lead to the counter-intuitive result that padding would only be initialized if there aren't enough initializers in the list.

If the C committee wants padding to be initialized, they know how to write that.

[pascal-cuoq]

@rjmccall I completely agree that it's ridiculous to initialize padding for struct s = { 0, 0 }; and not for struct s = {0, 0, 0}; when struct s has 3 members, but it is about exactly as ridiculous to initialize padding for the struct below and not for the cases above:

struct s {
  int i;
  struct {
      char c;
      int j;
  } s = {0};

If the C committee wanted to allow compilers to leave padding uninitialized in structs, surely they wouldn't have made it mandatory to zero the padding between c and j.

(I disagree on the C committee's ability to write what they want. The phrasing from C11 to C17 cannot be what anyone wants. QED.)

[AaronBallman]

If the C committee wanted to allow compilers to leave padding uninitialized in structs, surely they wouldn't have made it mandatory to zero the padding between c and j.

This is my understanding -- we don't want compilers to leave padding uninitialized in structs (that's an information leak security concern). I think C++ made it more clear than C did: http://eel.is/c++draft/dcl.init#general-6.2

[pascal-cuoq]

@AaronBallman Is this the sort of clarification that can go in a NB comment for C23, as long as it comes with a clear proposal for a change?

GCC's interpretation (as far as can be inferred from compiling example programs) is that padding should be initialized for {0, 0} but not for {0, 0, 0}. It would be great to get everyone on the same page for C23.

One counter-argument against mandatory zeroing of padding bits is that any write to a struct member makes the struct's padding indeterminate, so that this zeroing is barely observable. From the security point of view, leaving some padding unwritten reflects what happens to be on the stack is an arbitrarily bad information leak as you point out, and it would be great to find a wording that prevents this, but next we are going to have C compilers that skip the zeroing of the padding for the snippet below:

{
  struct s {
    char c;
    int i;
  } s = {0};
  s.c = 1; // C compiler: the padding doesn't need to be zeroed one line above since it's made indeterminate at this line

For this reason I would also understand if the proposed change for C23 went in the direction of padding initialization only for static-storage and const aggregates. Anything would be better than the current version, really.

[rjmccall]

Remember that "the same way as objects of static storage duration" is the general specification of zero initialization in the standard. It's extremely plausible that the committee just wanted to require declared members to be zero-initialized, and they reached for the existing formalization tool without considering that they were requiring padding to be initialized in subobjects. That would be consistent with the overall approach of not guaranteeing anything meaningful about padding except as a "freebie" for global initialization.

[AaronBallman]

@AaronBallman Is this the sort of clarification that can go in a NB comment for C23, as long as it comes with a clear proposal for a change?

I think it's reasonable as it's a bug fix/clarification and not a request for a new feature.

One counter-argument against mandatory zeroing of padding bits is that any write to a struct member makes the struct's padding indeterminate, so that this zeroing is barely observable.

C improving constant expression evaluation means that this is potentially more observable these days/in the future than before. Consider:

struct S {
  char c;
  int i;
};

constexpr struct S s1 = {};
constexpr static struct S s2;
_Static_assert(s1 == s2, "do these match?"); // Not an ICE, so an extension but a plausible one

Remember that "the same way as objects of static storage duration" is the general specification of zero initialization in the standard. It's extremely plausible that the committee just wanted to require declared members to be zero-initialized, and they reached for the existing formalization tool without considering that they were requiring padding to be initialized in subobjects. That would be consistent with the overall approach of not guaranteeing anything meaningful about padding except as a "freebie" for global initialization.

The argument I'm not hearing is who is served by treating C and C++ differently here. C++ very clearly specifies that padding is initialized during zero initialization. C was more hand-wavey in its specification, but I think it's quite reasonable to read it as intending to initialize padding as well.

I do not think users are served by struct S { char c; int i; } s = { 0 }; being safe in C++ and potentially leaking stack information in the padding bits in C.