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