Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch
Newsgroups: comp.lang.c
Subject: Re: Are designated initializer supposed to zero padding?
Date: Wed, 13 May 2026 15:51:33 -0700
Organization: A noiseless patient Spider
Lines: 37
Message-ID: <865x4qkjnu.fsf@linuxsc.com>
References: <10tqqso$kn23$1@dont-email.me> <10tr3ia$nak8$1@dont-email.me> <10trver$topc$2@dont-email.me> <10u010b$12a0c$1@dont-email.me> <10u0tiv$2egqj$1@kst.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Wed, 13 May 2026 22:51:33 +0000 (UTC)
Injection-Info: dont-email.me; logging-data="3179643"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+43FW7tNljx2sm/SPrPTIhercNJoSIXek="; posting-host="ace8b6eaa328dcf44f89a3207699c4cb"
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:HIEgMUxpacohZ/QuEPHGniDwP9o= sha1:RtO70U0nGImRyvL7kv1HPn1mMD8= sha256:5/kn8wNRkQXK2hvCjNQGFINYWZLPhNrgYMtKJ7Q7q84= sha1:claAH8kYq0vctra5bqSu3xm6D7Q=
Xref: csiph.com comp.lang.c:398912
Keith Thompson writes:
> James Kuyper writes:
>
>> On 2026-05-11 03:11, highcrew wrote:
>
> [...]
>
>>> I've seen this section in the standard, and I thought I found what
>>> I was seeking for, but isn't it just referring to static and
>>> thread-local variables?
>>
>> No, earlier in the same section it says quite explicitly: "... If an
>> object that has static or thread storage duration is not initialized
>> explicitly, or any object is initialized with an empty initializer,
>> ...". Objects with automatic storage duration are still covered by the
>> second clause of that sentence.
>
> Yes, but only automatic storage duration objects with an empty
> initializer. An "empty initializer" is `{}`, which wasn't even
> legal pre-C23. `{0}` is often used to (try to) achieve the same
> effect; it specifies a value of 0 for the (recursively) first scalar
> subobject, and leaves everything else to be default-initialized.
>
> I have a feeling that there's something inconsistent about the
> C23 rules. I'm working on nailing down the specifics.
>
> As a programmer, perhaps the best approach is to arrange things so
> you don't have to care about what's stored in padding. That might
> mean that you can't use memcmp() to confirm that a struct has the
> right value; you have to compare member by member.
My preference would be for a compiler option (eg -fzero-padding) or
a pragma (eg #pragma ZERO_PADDING=ON) or perhaps both. Either of
those has advantages over changing the language definition, not the
least of which is they can be retrofitted to earlier versions of C
without needing to break conformance.