Obscure C code (was Re: Excessive optimization)
Sean Conner
spc at conman.org
Tue Dec 7 16:30:05 CST 2010
It was thus said that the Great Brent Hilpert once stated:
>
> Agreed that double negation is not a fix to the error of said broken
> compiler, but I wasn't sure that was Sean's point in suggesting double
> negation.
I was replying to the following:
It was thus said that the Great Philip Pemberton once stated:
> So you use the unary negation operator, which turns your 0x80 (true)
> into 0 (false). "TF"[0] is "T", because the original value was true.
> Similarly, !0 = 1, and "TF"[1] is "F".
>
> However: the compiler would still be correct to use the value 123
> instead of 1, thus that code may not work... So it's compiler dependent,
> but most compilers use 0/1 for boolean results, meaning you might not
> spot the Big Nasty Bug until much, much later.
Which I don't think is correct compiler behavior, and (ha ha-half
seriously) suggested the double negation.
> You nonetheless agreed with Phil's assertion that it was
> compiler-dependant behaviour.
-spc (don't think it's compiler-depenant behavior, but I avoid
logical negation in my own C code ... )
More information about the cctalk
mailing list