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: Mon, 11 May 2026 15:19:55 -0700 Organization: A noiseless patient Spider Lines: 69 Message-ID: <86wlx9pp10.fsf@linuxsc.com> References: <10tqqso$kn23$1@dont-email.me> <86jytar6n2.fsf@linuxsc.com> <20260511232247.00006c5e@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Mon, 11 May 2026 22:19:58 +0000 (UTC) Injection-Info: dont-email.me; logging-data="1569546"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX188Hxlnz3IBCSUufVFMRacYdRiVILbbUo0="; posting-host="e12ff559fd79fb3307443db8d47ea871" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:wqsJE+swt/LEjN3c6MO4aqTwOLk= sha1:OQAXe8b1y8U3mLqWj4C6bquVUfw= sha256:zPB4+45quZHkJTG4i/7MzfwB35JiJCVTWjD8MUPuVIM= sha1:WfMhstbYiaKCYx16GhPa6quwd7Q= Xref: csiph.com comp.lang.c:398783 Michael S writes: > On Sun, 10 May 2026 20:01:53 -0700 > Tim Rentsch wrote: > >> Point 1: initializers are not required to set padding (either >> padding bits or padding bytes). Don't expect padding to be >> zeroed. This statement applies to initializers in all forms - >> regular initializers, designated initializers, and compound >> literals. > > James Kuyper says that zeroing of padding is required by that standard. > I am not an expert in lawyer-style reading of the standard, but at my > level it looks that he is correct and the wording in unequivocal. > For example, n3220, 6.7.11: > > 11 > If an object that has automatic storage duration is not initialized > explicitly, its representation is indeterminate. If an object that has > static or thread storage duration is not initialized explicitly, or > any object is initialized with an empty initializer, then it is subject > to default initialization, which initializes an object as follows: > ? if it has pointer type, it is initialized to a null pointer; > ? if it has decimal floating type, it is initialized to positive zero, > and the quantum exponent is implementation-defined; > ? if it has arithmetic type, and it does not have decimal floating > type, it is initialized to (positive or unsigned) zero; > ? if it is an aggregate, every member is initialized (recursively) > according to these rules, and any padding is initialized to zero bits; The problem is padding is none of those things. Padding (1) does not have pointer type; (2) does not have decimal floating type; (3) does not have arithmetic type; (4) is not a struct, a union, or an array; (5) is not a member of any struct or union; (6) is not an element of any array; and (7) is not an object, as the C standard uses the term. To see these are true, for 1 to 6, it's enough to note that all of them have a type. Padding does not have a type. For number 7, the C standard defines object as a region of storage, the contents of which can hold values. To hold a value, an object has to have a type. Padding does not have a type. We can see from other parts of the C standard that it doesn't consider padding to be objects. In 6.2.6.1 paragraph 6, the C standard says When a value is stored in an object of struct or union type, including in a member object, the bytes of the object representation that correspond to any padding bytes take unspecified values Note the wording used: the text doesn't talk about padding objects, it says "the bytes of the object representation that correspond to any padding bytes". The C standard doesn't consider the space occupied by padding to be an object, or a subobject of the struct or union surrounding it. For that matter, initializing a struct or a union stores a value in it. By the paragraph quoted above, any padding bytes take unspecified values. So not necessarily zero. Of course there is nothing stopping an implementation from setting all the padding bytes (and padding bits, if there are any) to zero; but the C standard does not require it.