indeterminate value leading to undefined behavior?

[Mantorok Redgormor]

In this context would an indeterminate value lead
down the path to undefined behavior?

(void)foo->member;

I want to keep my interface consisent in my program
so I have this one function which is passed an argument
that it doesn't need.

So I can only think of using it this way as a viable method
of staying consistent with my interface

That is, within a struct I have a pointer to a function
so I can't really change the interface as several other functions
rely on this particular argument.

So if member had an indeterminate value
would it be undefined behavior to use it
in the manner specified above?

I know casting it to (void) does not yield a value
so this is why I am unsure.

 

[Ian Woods]

(e-mail address removed) (Mantorok Redgormor) wrote in

In this context would an indeterminate value lead
down the path to undefined behavior?

(void)foo->member;

If foo->member points somewhere sensible, this is a no-op...

If foo->member has an indeterminate value, this would count as undefined
behaviour I think.

I want to keep my interface consisent in my program
so I have this one function which is passed an argument
that it doesn't need.

If it doesn't need it, and it's indeterminate, don't use it! There's
nothing wrong with passing an argument to a generic interface which doesn't
get used in some functions with that interface.

<snip>

To be honest, I can't think of any reason why you'd want to do the no-op
even if foo->member has a sensible value. Perhaps you should explain why
you want to do such a thing?

Ian Woods

 

[Martin Dickopp]

In this context would an indeterminate value lead
down the path to undefined behavior?

(void)foo->member;

I'm 95% sure that it is in fact undefined behavior. If the expression
statement

foo->member;

led to undefined behavior, you cannot avoid this by casting the expression
to void. The section in the standard about conversions to 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.
| 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.)

states that the expression is still evaluated (which would already be
undefined behavior in your case), even if its value is discared
afterwards.

If any C expert disagrees with my interpretation of the standard, I'd be
curious to hear why.

Martin

 

[Peter Nilsson]

I'm 95% sure that it is in fact undefined behavior. If the expression
statement

foo->member;

led to undefined behavior, you cannot avoid this by casting the expression
to void. The section in the standard about conversions to 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.
| 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.)

states that the expression is still evaluated (which would already be
undefined behavior in your case), even if its value is discared
afterwards.

If any C expert disagrees with my interpretation of the standard, I'd be
curious to hear why.

I'm no C expert, nor do I disagree with your assertion, but I'll comment
anyway.

6.8.3p2 (Expression and null statements) states "The expression in an
expression statement is evaluated as a void expression for its side
effects."

So, it doesn't matter whether there's a void cast or not, the expression is
evaluated on the virtual machine. Of course, optimising out statements with
no side effects is perfectly within the realm of 'undefined behaviour' in
the situation where the evaluation may involve an indeterminate value.