Hah. somehow it'd never occurred to me... Hopefully because I never needed it like this... otherwise there may be bugs all over the place completely unknown.

---------------

So, "TRUE" in the sense of

if(something){<do something else>}

... is whenever something is non-zero. NON-ZERO.

Right, that's easy... and quite handy.

Checking whether a pin is high on a port...?

if( PORTA_INPUT_REGISTER & (1<<pinNum) ) { ... }

does the trick quite nicely...

And, with optimization, that's nothing more than a <read-register> and an <and> (the left-shift is turned into a constant, assuming pinNum is a constant).

Okie Dokie!

So now, let's use that somewhere a bit more complex... right? Not sure *why* exactly, but say you want to for some reason...

e.g.

uint8_t portInputs = PORT_INPUT_REGISTER;

if ( portInputs & (1<<pinNum) ) { ... }

Awesome.

Now say you're using that as an output to a function... why-not-eh?

//Returns NON-ZERO when the pin is high
//ZERO when it's low
uint8_t IsPinHigh(uint8_t pinNum)
{
   return ( PORT_INPUT_REGISTER & (1<<pinNum) ); 
}
...
if(IsPinHigh(3)) { ... }

Woot, it's all good...

So, doing-so this way saves quite a few instructions... Another way of doing something like this would be to have IsPinHigh() return ONE (the value, 0x01) if the pin is high, rather than NON-ZERO. But, doing-so requires an additional test, a non-zero test. which I guess would probably only be one or two instructions, but they're instructions, nonetheless. Another way, still, (and more obvious to me, for some reason) would be to >> the result back, e.g.:

uint8_t IsPinHigh(uint8_t pinNum)
{
   return ( ( PORT_INPUT_REGISTER & (1<<pinNum) ) >> pinNum ); 
}

So, now you've got a ton of instructions... but your output is either 0 or 1, rather'n 0 or (1<<pinNum).

Anyways, we *know* it's going to be used *only* in cases where non-zero or zero is what matters... e.g. in if(IsPinHigh()) statements, so why waste all those extra instructions?

Now, who knows, maybe you want it to be a little more complex, still... I dunno why... (back to the Zero v. Non-Zero example):

Or, heck, don't even bother making it more complex... We've got a pretty good setup, here. It works great!

Awesome. Now move that same bit of code to another processor, maybe a 32-bitter, where the Port-Registers are 16bits wide...

//Returns NON-ZERO when the pin is high
//ZERO when it's low
uint8_t IsPinHigh(uint8_t pinNum)
{
   return ( PORT_INPUT_REGISTER & (1<<pinNum) ); 
}
...
if(IsPinHigh(13)) { ... }

Whoops.

Duh.

See it?

I mean, all we care about is a boolean value, yahknow, it's either true or not true... That *easily* fits in a uint8_t. But... Yeah. Probably not worth all this explanation, really, because yahknow it's so blatantly obvious, here... Even more fun when you're porting code that's already been written and long-functional and it's not all spelled-out for you like this.

And worse, still, when the return-value of IsPinHigh() is stored in *yet another* variable, which may well be uint8_t as well...

Oy.

So, here's a nastier example where it might be *slightly* less-obvious.

//Returns NON-ZERO when the pin is high
//ZERO when it's low
uint8_t IsPinHigh(uint8_t pinNum)
{
   return ( PORT_INPUT_REGISTER & (1<<pinNum) ); 
}

//If isTrue is NON-ZERO, then doSomething
//If isTrue is ZERO, then don't doSomething
void doSomethingWhenTrue(uint8_t isTrue)
{
    if(isTrue)    { ... }
}
...

int pinIsHigh = IsPinHigh(3);
doSomethingWhenTrue(pinIsHigh);

Or, imagine you saw the glaring fact of IsPinHigh()'s return-value, and fixed it *right away*, but instead of pinIsHigh having been an int, instead it was a uint8_t... Or, yahknow, there might be any number of combinations wherein it might even get missed by -Wconversion (see below).

FYI: -Wconversion is a handy argument to throw at gcc... but you'll also get to see just how many conversions happen behind the scenes that you don't usually think about... E.G. did you know that ~(0xff) becomes an *int* (rather than the uint8_t it started as)? So, typedef or #define a new type for a case like this. Run it once as the uint8_t it was, capture the output from gcc (with all those gazillions of new warnings) and run it again with the new uint16_t (or 32) and *diff* the outputs from the two runs... helpful, but probably not guaranteed to find *every* case.