C - is an indeterminate value indeterminable?

Question

According to this post an indeterminate value is:

3.17.2
1 indeterminate value
either an unspecified value or a trap representation

Accordi

Answer 1

We can not determine the value of an indeterminate value, even under operations that would normally lead to predictable values such as multiplication by zero. The value is wobbly according to the new language proposed(see edit).

We can find the details for this in defect report #451: Instability of uninitialized automatic variables which had a proposed resolution bout a year after this question was asked.

This defect report covers very similar ground to your question. Three questions were address:

1. Can an uninitialized variable with automatic storage duration (of a type that does not have trap values, whose address has been taken so 6.3.2.1p2 does not apply, and which is not volatile) change its value without direct action of the program?
2. If the answer to question 1 is "yes", then how far can this kind of "instability" propagate?
3. If "unstable" values can propagate through function arguments into a called function, can calling a C standard library function exhibit undefined behavior because of this?

and provided the following examples with further questions:

unsigned char x[1]; /* intentionally uninitialized */
printf("%d\n", x[0]);
printf("%d\n", x[0]);

Does the standard allow an implementation to let this code print two different values? And if so, if we insert either of the following three statements

x[0] = x[0];
x[0] += 0;
x[0] *= 0;

between the declaration and the printf statements, is this behavior still allowed? Or alternatively, can these printf statements exhibit undefined behavior instead of having to print a reasonable number.

The proposed resolution, which seems unlikely to change much is:

• The answer to question 1 is "yes", an uninitialized value under the conditions described can appear to change its value.
• The answer to question 2 is that any operation performed on indeterminate values will have an indeterminate value as a result.
• The answer to question 3 is that library functions will exhibit undefined behavior when used on indeterminate values.
• These answers are appropriate for all types that do not have trap representations.
• This viewpoint reaffirms the C99 DR260 position.
• The committee agrees that this area would benefit from a new definition of something akin to a "wobbly" value and that this should be considered in any subsequent revision of this standard.
• The committee also notes that padding bytes within structures are possibly a distinct form of "wobbly" representation.

Update to address edit

Part of the discussion includes this comment:

• Strong sentiment formed, in part based on prior experience in developing Annex L, that a new category of "wobbly" value is needed. The underlying issue is that modern compilers track value propagation, and uninitialized values synthesized for an initial use of an object may be discarded as inconsequential prior to synthesizing a different value for a subsequent use. To require otherwise defeats important compiler optimizations. All uses of "wobbly" values might be deemed undefined behavior.

So you will be able to determine a value but the value could change at each evaluation.