if() and TRUE vs FALSE

Maybe I got this idea from some other language, but I am convinced that if(xx) statements should execute if the variable xx is non-zero. You don't have to make the statement if(xx != 0). Am I missing something? I'm assuming false = 0 and true = non-zero.

Here's the issue:

Valve_err = 0x2A ;
if(Valve_err) {blah blah}

the blah blah is not executed.

We need to see your code.
Your actual code, not an uncompilable morsel.

Complete, compile-able, example that demonstrates the issue please.
Use code tags.

Maybe:

uint8_t Valve_err = 0x2A ;

setup() {
  byte Valve_err ;
  if(Valve_err) {blah blah}  //"unexpected" result
}

loop() {}

?

Thanks, all. I will work on my own debugging until I'm more frustrated than I am at the moment. Debugging is a learning process, so I like to do it up until I start looking for rope and making a 13 turn knot.

Regardless, that's not what I asked. What I asked (and was answered, with a few diversions to possible reasons the variable could be corrupt) was, is zero (0) equivalent to "false". One doesn't need to see 497 lines of code to answer that question.

If you formulate a question such that it is clear the answer is obvious to you, you will obviously get questions about why you are asking the question.

Delta_G:
Any non-zero value will evaluate as true.

Dr_Quark:
...zero (0) equivalent to "false".

These statements must be taken literally. Zero (0) is equivalent to false and any non-zero value will evaluate as true. Which is different than greater than zero. I have worked through many a learners program where the result of Valve_err (to use the example provided) turned out to be a negative number in which case was {blah blah} executed. The learner was not expecting the negative number and was also not expecting the conditional statements to execute. In some cases, the negative number should not have existed and the code was fixed elsewhere, in other cases the if statement was changed from (Valve_err) to (Valve_err>0).

is zero (0) equivalent to "false".

It is, but it is often MUCH clearer if you actually type a few extra characters and make the comparison clear.

if(digitalRead(somePin))
{
   // Value was HIGH

is nowhere near as clear as

if(digitalRead(somePin) == HIGH)

if(digitalRead(somePin) == HIGH)
A few more characters adds to commenting your code.
For sure, we have all done this:
#define PUSHED LOW
. . .
if(digitalRead(somePin) == PUSHED)

However there are those that like to be cryptic.
if(digitalRead(somePin))

No, it's not being cryptic. It's when you have a byte that is made up of various error flags and you want to execute a particular thing if any flag is set.

so

If(err_byte) {}

is a lot simpler than analyzing each bit in the err_byte.

I also agree with those who are concerned when

int OFF = 1 ;
int ON_ = 0 ;
digtalWrite(pinX, OFF) ;

easy to read, but it obscures negative logic

BTW, found the problem. There was an error function executed within the blah blah

if(Valve_err) {blah blah}

that did an escape and halted the sketch. So the if() was executing properly. Thanks again to All.

Dr_Quark:
I also agree with those who are concerned when

int OFF = 1 ;
int ON_ = 0 ;
digtalWrite(pinX, OFF) ;

easy to read, but it obscures negative logic

what's in a name?

#define MUSKRAT 1
#define MOTOR_HOME 0

digtalWrite(pinX, MOTOR_HOME) ;

What's wrong with a zero or a one? To me, LOW implies some smaller but nonzero value...

the HIGH/LOW macros are pedanticism at a new level!

¿get it...level!?!?
;D

What's wrong with a zero or a one? To me, LOW implies some smaller but nonzero value...
the HIGH/LOW macros are pedanticism at a new level!

It's sort-of a beginner's intro to the electronics they need to do "arduino-level things." What would it mean to "put a zero on a pin"?

    If(err_byte) {}

As a matter of style, I prefer my boolean values to be obviously boolean.

    If(err_byte != 0) {}

These days you can count on the compiler generating the same code in each case.

As a matter of style, I prefer my boolean values to be obviously boolean.

And for non-boolean variables to be compared to a value. At least, that's MY preference.

westfw:
What would it mean to "put a zero on a pin"?

I guess the same as coffee makers, cars, phones, cameras, etc...

Constructing expressions which rely on the internal representations of true, false etc. can lead to confusion and make code difficult (for someone else) to read. In not all languages does true have the value 1 and false the value 0. In visual basic, for example, true has the value -1. I guess also there are languages which prevent the use of true and false in anything other than a boolean context.

. In visual basic, for example, true has the value -1.

If it were possible, I now respect Microsoft even less.

6v6gt:
In not all languages does true have the value 1 and false the value 0. In visual basic, for example, true has the value -1. I guess also there are languages which prevent the use of true and false in anything other than a boolean context.

CtrlAltElite:
If it were possible, I now respect Microsoft even less.

That is why I was very specific on my response to the OP.

adwsystems:
Zero (0) is equivalent to false and any non-zero value will evaluate as true. Which is different than greater than zero.

Since I don't often work in VB (plus I also tend to be verbose in writing the if conditions while also programming under the mantra to not do anything in a way I will have to relearn two months from now), I forgot about this SNAFU. But as you see, even though true = -1, it is still a non-zero value.

CtrlAltElite:
If it were possible, I now respect Microsoft even less.

There is method in the madness.

False = 0
True is the inverse of False.
The inverse of 0 is 1

Therefore, a byte which is false looks like this,
00000000

The inverse looks like this,
11111111

The signed representation of 0 is
00000000

A bitwise subtraction of 1, causes the byte to wrap around
11111111
Which is -1

Therefore the signed representation of True is -1 and thanks to two's compliment, it works regardless of bit length

In visual basic, for example, true has the value -1.

I think that illustrates the point very well. There is no need to know what the value of true and false are as long as you always set the boolean variable to true or false and test it for true or false.