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.

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)

4 answers

You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.

+3
−0

It is undefined according to my reading of the standard (I am referring to the latest public draft).

int x;
(void)x;

In the second line, (void)x is a full expression, but x by itself is already an expression. For the expression x the following holds:

6.5.1 - 2: An identifier is a primary expression, provided it has been declared as designating an object (in which case it is an lvalue) or a function (in which case it is a function designator).

Thus, x being an identifer that is declared to designate an int object implies that x is a primary expression and an lvalue.

6.3.2.1 - 2: Except when it is the operand of the sizeof operator, the unary & operator, the ++ operator, the -- operator, or the left operand of the . operator or an assignment operator, an lvalue that does not have array type is converted to the value stored in the designated object (and is no longer an lvalue); this is called lvalue conversion. [...]

As the lvalue x is the operand of a cast operator (which is not in the above exception list) and as it is also no array type it is converted into the value stored in the object designated by x.

6.3.2.1 - 2: [...] If the lvalue designates an object of automatic storage duration that could have been declared with the register storage class (never had its address taken), and that object is uninitialized (not declared with an initializer and no assignment to it has been performed prior to use), the behavior is undefined.

As x has automatic storage duration, has never its address taken and is uninitialized, the behavior is undefined. (The point about the register storage class is to allow optimizations on certain processors. See the description of the "NaT" register state in this article about the Itanium processor.)

Note that it does not matter that x is part of a larger expression (void)x. But, just to extend on that aspect:

6.5 - 1: An expression is a sequence of operators and operands that specifies computation of a value, or that designates an object or a function, or that generates side effects, or that performs a combination thereof. The value computations of the operands of an operator are sequenced before the value computation of the result of the operator.

Important is the sequencing aspect here: The value of the operand x is computed before the result of the (void) operator is computed. The full expression will - in the end - have type void.

6.3.2.2 - 1: The (nonexistent) value of a void expression (an expression that has type void) shall not be used in any way, and implicit or explicit conversions (except to void) shall not be applied to such an expression. [...]

But this only says that you are not allowed to make further use of that void "result" of the expression (void)x.

6.3.2.2 - 1: [...] If an expression of any other type is evaluated as a void expression, its value or designator is discarded. (A void expression is evaluated for its side effects.)

Note that this does not say that the whole expression is discarded: Only its value (which is the result of the expression being evaluated) is discarded. The clause is there to make it clear that a void expressions is evaluated. The sentence in parentheses gives the reason why it is evaluated, namely because it may have side effects. The sentence does not say that it is only evaluated if it has side effects.

Therefore, it is also not possible to argue that the "undefinedness" stated above becomes irrelevant because the whole expression would be discarded: The expression just won't be discarded, only its result.

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

0 comment threads

+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)
+5
−0

It depends. This boils down to whether or not the expression cast to void contains any side effects, such as accessing a volatile-qualified object or modifying any object.

C17 6.3.2.2:

If an expression of any other type is evaluated as a void expression, its value or designator is discarded. (A void expression is evaluated for its side effects.)

In your example the cast operand does not contain any side effects so it is simply discarded, meaning that it is safe.

This would not be fine, however:

{
  volatile int x;
  (void)x; // undefined behavior, lvalue access of local uninitialized variable
}

While this is ok:

{
  int x;
  (void)(x=1); // well-defined, x is set to 1
  (void)function(x); // well-defined, function is called and the result discarded
}

Regarding all the details of when it is undefined behavior to use an uninitialized variable with an indeterminate value, check out this answer: (Why) is using an uninitialized variable undefined behavior? The explanation is not as trivial as "this is always ok" or "this is always UB". The type of the variable matters a lot - plain integers are for example very unlikely to contain trap representations, but floating-point variables or pointers (particularly) may do.

So this is not ok either:

{
  int x,y;
  (void)(x=y); // undefined behavior, lvalue access of local uninitialized variable y
}
History
Why does this post require moderator attention?
You might want to add some details to your flag.

1 comment thread

Excellent answer which shows how easy it is to get the standard wrong, as I did. (1 comment)
+0
−0

Well, an "uninitialized" variable is, in fact, not uninitialized as that terminology may suggest; it is just filled with random garbage that happened to be on that memory section. That is to say, uninitialized variables are not special, they just happen to not contain any meaningful value, but they do have a value.

void is not a type, rather the contrary -- it's the absence of type. Knowing this, casting to it wouldn't make much sense but as it happens, it is allowed; it simply discards the expression being cast.¹²

Now, casting to a void pointer (void*) is another thing. It's mostly used as a sort of "generics" in C (e.g, the standard qsort function uses this). Since these pointers are aligned as character ones³ and can be cast to any other pointer type, you can write functions that take void pointers but cast them to their concrete types inside, thus allowing a generic-like function signature (naturally, a whole lot less safe than what you may find in other languages).

Null pointers are essentially void pointers to an integer constant expression of value 0 and have the interesting property of being guaranteed that when cast to concrete pointer types, they will never be considered equal.⁴

Hope this answers your question, if not let me know in the comments :)


¹ From C's standard, section 6.3.2.2:

If an expression of any other type is evaluated as a void expression, its value or designator is discarded. (A void expression is evaluated for its side effects.)

² From C++'s standard, section 5.2.9.4:

Any expression can be explicitly converted to type cv void." The expression value is discarded.

³ From C's standard, section 6.3.2.3:

A pointer to void may be converted to or from a pointer to any incomplete or object type. A pointer to any incomplete or object type may be converted to a pointer to void and back again; the result shall compare equal to the original pointer.

And 6.2.5.27:

A pointer to void shall have the same representation and alignment requirements as a pointer to a character type.

⁴ From C's standard, section 6.3.2.3:

An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant. If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function.

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

1 comment thread

Don't confuse common implementations with the specification (3 comments)

Sign up to answer this question »