Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Review Suggested Edit

You can't approve or reject suggested edits because you haven't yet earned the Edit Posts ability.

# Yes, it is safe unless the variable is volatile.
The term used in the C99 standard for the value of an "uninitialized" variable is **indeterminate**.
From [C99 standard](https://www.dii.uchile.cl/~daespino/files/Iso_C_1999_definition.pdf):
Section 6.2.4 Storage durations of objects (emphasis mine):
> 5 For such an object that does not have a variable length array type, its lifetime extends
from entry into the block with which it is associated until execution of that block ends in
any way. (Entering an enclosed block or calling a function suspends, but does not end,
execution of the current block.) If the block is entered recursively, a new instance of the
object is created each time. **The initial value of the object is indeterminate.** If an
initialization is specified for the object, it is performed each time the declaration is
reached in the execution of the block; otherwise, the value becomes indeterminate each
time the declaration is reached.
Section 3.17.2 indeterminate value
>either an unspecified value or a trap representation
Section 3.17.3 unspecified value
>valid value of the relevant type where this International Standard imposes no requirements on which value is chosen in any instance
If the initial value of the object is unspecified then the code is OK. No undefined behaviour. The cast to (void) is irrelevant in this case, we can even read an uninitialized variable with unspecified value safely.
But, what if the variable is initialized to a trap representation?
Section 6.2.6 Representations of types - 6.2.6.1 General
> 5 Certain object representations need not represent a value of the object type. If the stored
value of an object has such a representation and is read by an lvalue expression that does
not have character type, the behavior is undefined. If such a representation is produced
by a side effect that modifies all or any part of the object by an lvalue expression that
does not have character type, the behavior is undefined. *(note 41)* Such a representation is called
a trap representation.
> note 41 : Thus, an automatic variable can be initialized to a trap representation without causing undefined
behavior, but the value of the variable cannot be used until a proper value is stored in it.
When casting the value to (void) we are not reading it by an lvalue expression. Hence it is safe.
Unless it is a volatile variable. In that case it is lvalue access and it would be undefined behaviour. The [excellent answer by Lundin](https://software.codidact.com/posts/286974/286987#answer-286987) has details on that.

# Yes, it is safe unless the variable is volatile.
The term used in the C99 standard for the value of an "uninitialized" variable is **indeterminate**.
From [C99 standard](https://www.dii.uchile.cl/~daespino/files/Iso_C_1999_definition.pdf):
Section 6.2.4 Storage durations of objects (emphasis mine):
> 5 For such an object that does not have a variable length array type, its lifetime extends
from entry into the block with which it is associated until execution of that block ends in
any way. (Entering an enclosed block or calling a function suspends, but does not end,
execution of the current block.) If the block is entered recursively, a new instance of the
object is created each time. **The initial value of the object is indeterminate.** If an
initialization is specified for the object, it is performed each time the declaration is
reached in the execution of the block; otherwise, the value becomes indeterminate each
time the declaration is reached.
Section 3.17.2 indeterminate value
>either an unspecified value or a trap representation
Section 3.17.3 unspecified value
>valid value of the relevant type where this International Standard imposes no requirements on which value is chosen in any instance
If the initial value of the object is unspecified then the code is OK. No undefined behaviour. The cast to (void) is irrelevant in this case, we can even read an uninitialized variable with an unspecified value safely.
But, what if the variable is initialized to a trap representation?
Section 6.2.6 Representations of types - 6.2.6.1 General
> 5 Certain object representations need not represent a value of the object type. If the stored
value of an object has such a representation and is read by an lvalue expression that does
not have character type, the behavior is undefined. If such a representation is produced
by a side effect that modifies all or any part of the object by an lvalue expression that
does not have character type, the behavior is undefined. *(note 41)* Such a representation is called
a trap representation.
> note 41 : Thus, an automatic variable can be initialized to a trap representation without causing undefined
behavior, but the value of the variable cannot be used until a proper value is stored in it.
When casting the value to (void) we are not reading it by an lvalue expression. Hence it is safe.
Unless it is a volatile variable. In that case, it is lvalue access and it would be undefined behaviour. The [excellent answer by Lundin](https://software.codidact.com/posts/286974/286987#answer-286987) has details on that.

Communities

Review Suggested Edit