Why so many people hate C? Because the C language assumes you know what you’re doing and lets you. If you don't know what you are doing you can learn or you can hate the language.
@lfa Or maybe life is too short to use a language that has so many wrong defaults, undefined/implementation-defined behaviors etc., when, instead of trying to remember all the things you shouldn’t do, you could just use a language that does the right thing by default, freeing your brain up to actually design and plan the parts that make your program special.
Maybe I'll finally know what I'm doing and will learn after another 29 years of writing C.
@PaniczGodek Sorry I thought you where talking about the conversions.
Your sample of the int overflow is going to get caught if you set the warning flags of the compiler, and because your affirmation sounded odd to me, I tested your sample on GNU/Linux with GCC 12 and on OpenBSD with clang 16 and I got exactly the same result.
@PaniczGodek@lfa oh yes the implicit conversion to int. It is even worse if you do: '\0x80' as in C++ it would the char type while in C it is still int. Oh and is char signed or unsigned depends on the target.
@PaniczGodek because char, unsigned char and signed char are integer types.
A char can contain a value from -128 up to 127. 0x80 is 128 so when you set 0x80 to a char variable it's going to overflow. That's why your if fails because you are comparing if your char is 128 and it's not.
If you use an unsigned char which can hold values from 0 to 255 then your if is going to work as expected.
@lfa Overflow is something that happens during arithmetic operations. When I set 0x80 to a char variable (assuming it's at least 8-bit wide), that variable contains exactly this value: 0x80 (or bit pattern 0b10000000). There is no overflow.
The problem arises with the operator ==, which performs a widening conversion of the variable to the "int" type, because it treats that variable as a signed value (which is implementation-dependent, which is a problem on its own), and instead of treating it as 0x80, it treats it as 0xFF80 (on 16-bit platforms) or 0xFFFFFF80 (on 32-bit platforms), because this is how widening conversion with 2's complement number representation works.