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.
Post History
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: Section 6.2.4 Storage duratio...
Answer
#6: Post edited
by
Ethan
·
2022-09-15T16:38:42Z (over 2 years ago)
- # 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.
#5: Post edited
by
Estela
·
2022-09-12T17:52:37Z (over 2 years ago)
- # 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 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.
#4: Post edited
by
Estela
·
2022-09-12T17:52:02Z (over 2 years ago)
- # 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 an expression with side effects 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 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.
#3: Post edited
by
Estela
·
2022-09-12T16:48:49Z (over 2 years ago)
- # 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 an lvalue expression 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 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 an expression with side effects and it would be undefined behaviour. The [excellent answer by Lundin](https://software.codidact.com/posts/286974/286987#answer-286987) has details on that.
#2: Post edited
by
Estela
·
2022-09-12T16:44:41Z (over 2 years ago)
# Yes, it is safe.- 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.
- # 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 an lvalue expression and it would be undefined behaviour. The [excellent answer by Lundin](https://software.codidact.com/posts/286974/286987#answer-286987) has details on that.
#1: Initial revision
by
Estela
·
2022-09-10T08:51:40Z (over 2 years ago)
# Yes, it is safe. 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.