Hacker News Reader

HNHacker News

Top New Best Ask Show Jobs

Comment by viraptor | Hacker News Reader

Parent Full thread

viraptor·

Not very intuitive, but easy to explain if you know the compiler stages.

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

View on HN

This is something that ANSI C (C89) fixed, introducing the idea of ‘preprocessing tokens’ used in some of the conceptual translation phases. The two ‘-’ are separate preprocessing tokens because they did not originally appear together, so they turn into separate C tokens ‘-’ ‘-’ rather than one ‘--’. (If preprocessed code needs to be represented as text again (e.g. output from cc -E) then white space between the two ensures this.)

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'm pretty sure the preprocessor goes first. BUT it appears to put a space in between the two -s, at least in my testing, so the result is the same.

That's the reason for ps... But either way - what I meant is that it doesn't run just a text replace, it has to split the tokens first. Otherwise SOME_MONE_TEXT would get turned into SOME_-1_TEXT too. Lexer has to detect where the whole token exists on its own and replace it with equivalent syntax.

GCC explains here:

http://gcc.gnu.org/onlinedocs/cppinternals/Token-Spacing.htm...

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.

Figures, something that looks relatively simple (the C preprocessor) ends up having a ton of complicated stuff going on underneath.

Reply on news.ycombinator.com