Several other tests reveal some more reliable compiler behavior than I've been expecting--I need to go back and brush up on my preprocessorfoo.
Basically what happens is: b-MONE -> lexer -> (b) (-) (MONE) -> preprocessor -> (b) (-) (-) (1) -> parser
And I think you expected: b-MONE -> preprocessor -> b--1 -> lexer -> (b) (--) (1) -> fail
PS. yeah, preprocessor+lexer are a bit more coupled, but that's the general idea
A pre-ANSI preprocessor would generally emit ‘--’, which the compiler would naturally recognize as a decrement operator. I'm not aware of any exceptions; pre-ANSI implementations diverged in various ways, but tended to follow either K&R 1 or Reiser (John, not Hans) CPP.
I can't find anything in the C spec that says this is strictly required, but that doesn't mean it's not in there.
But why IEEE has a special way of writing two?
Until recently, most compilers would do host arithmetic and then convert it to target bit pattern. You would get within epsilon equal values, but not always the same bit pattern.
Now all these compilers use multiprecision float libraries (either MPFR or custom-written), so the bit patterns will always come out the same.
As such, there is no need for the explicit bit patterns anymore, so they just use "2.0".
There also are floating instructions where CPUs do not compute all bits of the correct result. See http://www.zqna.net/qna/knvvzn-do-fp-operations-give-exactly....
Also, not all CPUs produce the same result. In https://blogs.oracle.com/jag/entry/transcendental_meditation, James Gosling claims:
"As far as I know, the K5 is the only x86 family CPU that did sin/cos accurately. AMD went back to being bit-for-bit compatibile with the old x87 behavior, assumably because too many applications broke"
Anyway, K5 was almost two decades ago. If you use recent processors, or even better avoid x87 instructions entirely, are you still going to have different float results?
Also, I think modern x86 has a "approximate 1/x" instruction that is there to be as fast as possible and, because of that, allows for differences in results. I don't know whether that is true, or whether different implementations actually exist, though.
Here is the patch that introduced the bug http://www.sourceware.org/git/gitweb.cgi?p=glibc.git;a=commi...