Requested clarifications for thread-local storage

To ensure that initialization for thread storage-duration objects follows the same rules as for static objects, it is necessary to get the same "byte-flooding" behavior for thread objects as for static objects. Today, this "byte-flooding" is specified in 5.1.2p1, and occurs (only) before program startup.

One way to get the same effect for thread storage-duration objects would be to duplicate the necessary statement -- somewhere -- to apply to thread startup as well as program startup. I am not enamored of this approach.

The direction I would prefer would be to describe the effect of "byte-flooding" at the point where zero-initialization is described. Therefore I propose to modify 6.7.8p10 along the following lines (note that the phrase "or thread" is added by N1364, and is presented here for completeness):

If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate. If an object that has static or thread storage duration is not initialized explicitly, then:

• if it has pointer type, it is initialized to a null pointer;
• if it has arithmetic type, it is initialized to (positive or unsigned) zero;
• if it is an aggregate, every member is initialized (recursively) according to these rules, and padding is initialized to zero bits;
• if it is a union, the first named member is initialized (recursively) according to these rules, and padding is initialized to zero bits.

Note two things:

• The word "padding" is used in dozens of places in the standard, without any formal definition. These new uses are consistent with existing statements about padding in structures and unions; see 6.7.2.1p13 and 15.
• Many occurrences of the word "padding" occur in the phrase "padding bits", which also has no formal definition, and which is used (nearly exclusively) to talk about representations of integer types. The proposed edits specifically do not refer to "padding bits", to avoid imposing new requirements on implementations where integers have padding bits.

With these changes, I believe the change to 5.1.2p1 described in N1311, and already applied to the WD, would become unnecessary.

The other clarification desired concerned the effect of initialization of thread-local objects on the floating-point status flags. Under the assumption that each thread has its own floating-point environment, there are two possibilities.

Initializing the thread-local objects of a new thread might affect the floating-point status flags of the new thread. Concerning this sort of situation, 7.6.1p2 states: "When execution passes from a part of the program translated with FENV_ACCESS "off" to a part translated with FENV_ACCESS "on", the state of the floating-point status flags is unspecified ...." In other words, as far as I can tell, the standard nowhere gives any guarantees about the initial state of the floating-point status flags. It would seem inconsistent to provide such guarantees for a new thread when they are not made for main, for example.

Initializing the thread-local objects of a new thread might affect the floating-point status flags of the thread that creates the new thread. Creation of a new thread will almost inevitably be performed by calling a library function. Concerning this, 7.6p2 already states that "a function call is assumed to have the potential for raising floating-point exceptions, unless its documentation promises otherwise." It would be possible to add such a promise to the description of thrd_create; lacking that, nothing that might be said anywhere else would be sufficient. Given that no other library function currently makes any such promise, it's not clear how much value there would be in starting with thrd_create.

In other words, promising that initialization of thread-local objects would not affect floating-point status flags would basically be inconsistent with the overall lack of such promises throughout the rest of the language and library.