Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

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.

Comments on Cast uninitialized variable to (void)

Parent

Cast uninitialized variable to (void)

+3
−0

Is it undefined behaviour to cast an uninitialized variable to (void)?

Example:

int main()
{
  int x;
  (void)x;
  return 0;
}
History
Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

2 comment threads

What are you trying to achieve? (3 comments)
I wonder if I should also tag this C++ also. The answer *might* be different for these different lang... (3 comments)
Post
+6
−0

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 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 has details on that.

History
Why does this post require moderator attention?
You might want to add some details to your flag.

2 comment threads

Some parts are not necessarily correct (3 comments)
Unsure about the trap representation scenario. (2 comments)
Some parts are not necessarily correct
Lundin‭ wrote over 1 year ago · edited over 1 year ago

"we can even read an uninitialized variable with unspecified value safely" This is an over-simplification. Reading a local variable (automatic storage) which was not initialized and never had its address taken (could have been declared with register storage class) is explicitly UB as per C17 6.3.2.1. That doesn't apply to the code in the question since it contains no side effects and x is actually never read. But it could apply in other situations.

Estela‭ wrote over 1 year ago

No, it is not an over-simplification. The standard states in 3.17.3 that unspecified values are valid. Hence they can be used in all scenarios where valid values can be used. This does not contradict your scenario. It just means that in your scenario the the variable cannot be holding an unspecified value.

Lundin‭ wrote over 1 year ago

The volatile part doesn't make it UB because of the lvalue access alone, but because of the special rule in 6.3.2.1 which has nothing to do with the value of the variable or traps, but code generation.