"Fun bug of the month, mesa edition, episode may"
-
"Fun bug of the month, mesa edition, episode may"
so if you do "uint64_t some_var = 1 << 31;" in C you get "0xffffffff80000000" as the value, because that's super obvious and not confusing at all.
It's pretty funny getting reminded how non-intuitive and broken C is from time to time.
@karolherbst I recently read https://www.os2museum.com/wp/bitfield-pitfalls/ which is a similar pitfall?
-
@karolherbst @trilader Yeah, travelling to 1972 and changing the language would be best :-).
-
"Fun bug of the month, mesa edition, episode may"
so if you do "uint64_t some_var = 1 << 31;" in C you get "0xffffffff80000000" as the value, because that's super obvious and not confusing at all.
It's pretty funny getting reminded how non-intuitive and broken C is from time to time.
@karolherbst taking off my "understands sign extension" badge
wore it with pride, but the pride was misplaced
-
@karolherbst For my understanding: That's default int promotion + sign extend on 64 bit extension? Would 1L << 31L fix this or is there other pitfalls with that?
@trilader @karolherbst 1L << alone would do the trick on real world 64-bit machines, but i think compiler is still fully allowed to do the wrong thing. msvc perhaps still has 32-bit longs on 64-bit platforms?
i think you need to make sure it's unsigned so that sign extension has no chance of occurring, so my money is on 1U << 31?
-
"Fun bug of the month, mesa edition, episode may"
so if you do "uint64_t some_var = 1 << 31;" in C you get "0xffffffff80000000" as the value, because that's super obvious and not confusing at all.
It's pretty funny getting reminded how non-intuitive and broken C is from time to time.
@karolherbst ohhh, footgun i didn't know about yet!
