Assigning a bool a numeric value -- please help!

[Richard]

C's logical and comparison operators all return int. So do other
seemingly logical tests like isspace. You need to know not only the
type but the range of possible return values in order to use all of
these correctly. If all of these returned _Bool, then you would have
one less thing to think about, but the boat sailed on that one years
ago.


Keith seems to me to be doing quite the opposite. He is warning that
the messy history of C means that you can be easily mistaken about
what types are used in various situations.

You can over state things. 0 or non zero. Bool.

What do you hope to gain by being rude? Please remember Thumper's
mother.

There was nothing rude there. I was offering advice as to using C as an
efficient low hevel, touch the HW language.

 

[Don Bruder]

That statement is either incorrect or strangely written, depending
on whether the reader interprets the '!' as a C '!'.

Suggested fix: "(which is either true(1) or false(0))".

Except that any non-zero value (including, but not limited to, 1) is
"true" so far as the language is concerned.

Which means that your "fix" is not only wrong, but worse than worthless.

 

[Antoninus Twink]

Except that any non-zero value (including, but not limited to, 1) is
"true" so far as the language is concerned.

Of course...

Which means that your "fix" is not only wrong, but worse than worthless.

....but I think you have misunderstood the point.

The discussion was not about any old value, but specifically the value
of a boolean expression like (a >= b). The value of such an expression
will always be either 1 or 0, and I agree with Han that !0 is a
pointlessly obscure way to write 1.

 

[Nelu]

I know. The context indicates I'm replying to your statement:

"so you are assigning the result of '>=' (which is either true(!0) or
false (0)) to somebool."

This says the result of '>=' is either true(!0) or false(0).

So you are using "true" to mean not ">= is true" but "what the standard
calls true in general"? In that case, you're correct, but the reader
could still assume you mean ">= is true".

Oh, I see. I was referring to true the same way the standard does that's
why I used !0. Sorry for the misunderstanding.

 

[CBFalconer]

.... snip ...

That doesn't mean you should use it as such. Adding multiplying
and dividing these results is not what they're for. You Can do
it, but what will do with the result? This isn't the type I'm
talking about - it's the intent. How often is something like
((a < b) + (b < c) + (c < d)) / ((a > b) + (b > c)) used?

However, you can use an expression such as:

((a < b) == (b < a))

perfectly safely, because you know that relations return either 0
or 1 as their values. If you think about it you will find valuable
places for this usage.

 

[Richard]

However, you can use an expression such as:

((a < b) == (b < a))

perfectly safely, because you know that relations return either 0
or 1 as their values. If you think about it you will find valuable
places for this usage.

I've thought about it. You have one up on me for a change. Where is this
useful?

 

[Richard Tobin]

we can produce ((a < b) == (b < a)) from the logically equivalent (a == b).

The expressions are not equivalent. If a or b is a floating-point
NaN, a == b is false, but (a<b) == (b<a) is true.

-- Richard

 

[J. J. Farrell]

The standard uses a non-zero (not necessarily one) value for true even if
'>=' will return 1.

I was talking about truth values not about the boolean macros.

That may be what you meant to talk about; what you actually talked about
was "the result of '>='" which is either 1 or 0.

 

[CBFalconer]

The expressions are not equivalent. If a or b is a floating-point
NaN, a == b is false, but (a<b) == (b<a) is true.

I think Han has, as usual, missed the entire point. The fact that
relationships return only the integers 0 and 1 enables such
comparisons between relationships to be meaningful. He might try
interpreting the following:

int whatisthis(const char *a, const char *b) {

while (*a == *b) a++, b++;
return (*a > *b) - (*b > *a);
} /* whatisthis */

 

[CBFalconer]

Unless I'm missing something, it looks like a strncmp type
function that won't like matching strings much.

Close. Actually, I was missing something. See the added term in
the while. The point is the returned expression, which doesn't
cause any jumps in the code, and can thus avoid slowdowns.

 

[Kaz Kylheku]

int whatisthis(const char *a, const char *b) {

while (*a == *b) a++, b++;
return (*a > *b) - (*b > *a);
} /* whatisthis */

What is this? Luckily, code that will never make it into production.

 

[Keith Thompson]

Close. Actually, I was missing something. See the added term in
the while. The point is the returned expression, which doesn't
cause any jumps in the code, and can thus avoid slowdowns.

Leaving aside the question of whether the code is correct, how do you
know it won't cause any jumps? If the CPU happens to have an
instruction that evaluates x > y and yields a result of 0 or 1, it
probably won't; otherwise, the compiler might have to generate a
conditional jump to compute the proper value.

 

[Stephen Sprunk]

Harold Aptroot wrote:
... snip ...

However, you can use an expression such as:

((a < b) == (b < a))

perfectly safely, because you know that relations return either 0
or 1 as their values. If you think about it you will find valuable
places for this usage.

IMHO, that is a poor example. However, I sometimes find myself writing
code like this:

a += (b != c);

which is equivalent to:

if (b != c) a++;

but the former has advantages in some circumstances because it's an
expression, not a statement. Some compilers may also do better with the
former version on hardware (e.g. x86) that can generate an integer 0 or
1 result from a comparison without a branch, though a smart enough one
might generate identical code for both versions.

S

 

[Bruce Cook]

Close. Actually, I was missing something. See the added term in
the while. The point is the returned expression, which doesn't
cause any jumps in the code, and can thus avoid slowdowns.

Actually it's likely that it will cause jump, as the compiler has to
normalize the compare result flags from the > and < operators into an
integer (or bool if you want to be a pedant and quote C99) to then compare.

Just because you can write it with less lines, braces etc in the higher-
level language, doesn't mean it's actually more efficient in reality.

This is one of the arguments that was going on in the initial
standardization process for C.

Bruce

 

[Keith Thompson]

Actually it's likely that it will cause jump, as the compiler has to
normalize the compare result flags from the > and < operators into an
integer (or bool if you want to be a pedant and quote C99) to then compare.

No, if you want to be pedantic and quote C99, it's still int.

 

[Bruce Cook]

No, if you want to be pedantic and quote C99, it's still int.

Damn!, Instead of second-guessing the pedants, I just armed them !



Bruce