Compiler error or my mistake

[jwes]

The c standard says that that compound if statements do not evaluate
the second part if the first part is false, e.g. "if (str && *str)"
does not give an error if str is null. I wanted both parts evaluated,
so I put extra parentheses "if ((a && b))", and one popular compiler
still did not evaluate b if a is false. Is this a compiler error?

 

[Kenny McCormack]

The c standard says that that compound if statements do not evaluate
the second part if the first part is false, e.g. "if (str && *str)"
does not give an error if str is null. I wanted both parts evaluated,
so I put extra parentheses "if ((a && b))", and one popular compiler
still did not evaluate b if a is false. Is this a compiler error?

Yes. In the sense that what you fed to the compiler was in error.
There was an error in the way you were using the compiler.

 

[Eric Sosman]

The c standard says that that compound if statements do not evaluate
the second part if the first part is false, e.g. "if (str && *str)"
does not give an error if str is null. I wanted both parts evaluated,
so I put extra parentheses "if ((a && b))", and one popular compiler
still did not evaluate b if a is false. Is this a compiler error?

The compiler acted correctly.

It's not about `if' statements as such, but about the `&&'
operator in whatever context it appears -- in an `if', `while',
`for', `do..while', or even just on its own. The right-hand
operand is evaluated *only* if the left-hand operand is true.

If you want to evaluate both `a' and `b', don't use `&&'.
Use `&' instead -- but beware of its slightly different
precedence, and use parentheses liberally.

 

[James Kuyper]

The compiler acted correctly.

It's not about `if' statements as such, but about the `&&'
operator in whatever context it appears -- in an `if', `while',
`for', `do..while', or even just on its own. The right-hand
operand is evaluated *only* if the left-hand operand is true.

If you want to evaluate both `a' and `b', don't use `&&'.
Use `&' instead -- but beware of its slightly different
precedence, and use parentheses liberally.

When 'a' and 'b' are 'str' and '*str' respectively, using '&' instead of
'&&' would be a constraint violation.

 

[Keith Thompson]

When 'a' and 'b' are 'str' and '*str' respectively, using '&' instead
of '&&' would be a constraint violation.

Right. You could use

if (!!str & !!*str)

but I wouldn't do it that way. I might use something like:

some_type lhs = str;
some_type rhs = *str;
if (lhs && rhs) ...

Incidentally, (str && *str) is not a good example; it's a case where
you *really* don't want to evaluate the right operand if the left
operand is false.

 

[Seebs]

The c standard says that that compound if statements do not evaluate
the second part if the first part is false, e.g. "if (str && *str)"
does not give an error if str is null. I wanted both parts evaluated,
so I put extra parentheses "if ((a && b))", and one popular compiler
still did not evaluate b if a is false. Is this a compiler error?

No. Why on earth would you think the parenthesis would change something?

"I heard that some cars won't start without a key in the ignition. I
buckled my seatbelt, but one popular car still wouldn't start without
a key in the ignition. Is this a car error?"

-s

 

[Nick Keighley]

Yes.  In the sense that what you fed to the compiler was in error.
There was an error in the way you were using the compiler.

in other words:
No. In the sense that the compiler was operating correctly

 

[Ben Bacarisse]

No. Why on earth would you think the parenthesis would change something?

The OP explains why in the first sentence. If one believes that the
if's initial "(" is followed by some clauses that are separated by &&
then it makes sense that grouping two of them into one might alter
the execution.

Of course, you and I both know that it does not make sense for C to be
designed that way, but it takes some time to get there.

<snip>