This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 110c. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2023-02-07


694. Zero- and value-initialization of union objects

Section: 9.4  [dcl.init]     Status: C++11     Submitter: Clark Nelson     Date: 14 May, 2008     Liaison: WG14

[Voted into the WP at the November, 2010 meeting.]

The C committee is considering changing the definition of zero-initialization of unions to guarantee that the bytes of the entire union are set to zero before assigning 0, converted to the appropriate type, to the first member. The argument (summarized here) is for backward compatibility. The C++ Committee may want to consider the same change.

Proposed resolution (August, 2008):

Change bullet 3 of 9.4 [dcl.init] paragraph 5 (in the first list, dealing with zero-initialization) as follows:

[Drafting notes: Ask a C liaison about the progress of WG14 paper N1311, which deals with this issue. Since the adoption of WG21 paper N2544, unions may have static data members, hence the change to refer to the first non-static data member and the deletion of the footnote.]

Notes from the September, 2008 meeting:

It was observed that padding bytes in structs are zero-initialized in C, so if we are changing the treatment of unions in this way we should consider adding the C behavior for padding bytes at the same time. In particular, using memcmp to compare structs only works reliably if the padding bytes are zero-initialized.

Additional notes (February, 2010):

The C Committee has changed its approach to this question and is no longer using a two-phase process; in C, zero-initialization is specific to program start-up and thus is not appropriate for use with thread-local storage. See C paper N1387.

Proposed resolution (October, 2010):

Change 9.4 [dcl.init] paragraph 5 as follows:

To zero-initialize an object or reference of type T means: