If you want to test a against b, 0x00 is not equal to 0xFF
If you assign ~0xFF to b, b will contain 0x00. And 0x00 is equal to 0x00.
.
You can get anomalies when you compare an int with an unsigned.
Or if you compare an unsigned with a negative literal.
.
Please copy-paste when asking questions. i.e. get your spelling correct.
.
Confession. I am replying on a tablet.
.
David.

I made spelling mistakes trying to write fast an example. The code is full with other statement that have nothing to do with the question... I learned my lesson, sorry

clawson wrote:

But see what happens if I don't cast the results:

On your example you used the casting:

(uint8_t)a==(uint8_t)~b

on variables that were already uint8_t. It also solved my problem but why does this need to be done? Yes, I know is a very basic question. I am not new to C, just bad at it if you will :) ,but I have never noticed this.

For fun, I changed the variables to "unsigned int" in GCC. Then the optimizer reared its head and knew what the result would be. So I needed "volatile"...

Thanks a lot for going through the trouble of testing it on both compilers, theusch (and for the sceenshots).

Changing them to unsigned int instead of char also worked with no castings necessary. But I have to be honest, I still don't understand what basic rule of C I am not paying attention to or could this really just be related to AVR/GCC like you asked above?

True dat. I didn't need the cast on the left - was being a bit over eager. The following would have been OK:

a==(uint8_t)~b

The point being that the result of ~ is not uint8_t. I always have to go and look it up but I believe it'll be promoted to "(signed) int" which is why the 0xFFFFFFFF was seen when it was printed - this is of course on a PC where sizeof(int)==4. On an AVR the result was likely 0xFFFF but, still, 0xFFFF != 0xFF which is why the comparison failed.

BTW I switched from test.c to test.cpp here as I thought <typeinfo> and typeid(a).name() and stuff looked very interesting but I ditched the idea because the support in G++ in Linux does not seem as extensive as in MSVC that I was reading about. GNU just outputs mysterious one letter type IDs from the .name() method while apparently MSVC pushes the boat out with fully worded type names. I can't help thinking it could be a good learning tool (for ALL of us!) to explore <typeinfo> in C++ ! It will actually tell you what the type of ~a is without you having to dig out the C manual.