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.