Re: [Haskell-cafe] More Language.C work for Google's Summer of Code

On 19:54 Tue 30 Mar , Stephen Tetley wrote:

On 30 March 2010 18:55, Serguey Zefirov wrote:

...

Other than that, C preprocessor looks simple.

Ah no - apparently anything but simple.

I would describe it as "simple but somewhat annoying". This means that guessing at its specification will not result in anything resembling a correct implementation, but reading the specification and implementing accordingly is straightforward. Probably the hardest part is expression evaluation.

You might want to see Jean-Marie Favre's (very readable, amusing) papers on subject. Much of the behaviour of CPP is not defined and often inaccurately described, certainly it wouldn't appear to make an ideal one summer, student project.

The only specification of the C preprocessor that matters is the one contained in the specification of the C programming language. The accuracy of any other description of it is not relevant. C is quite possibly the language with the greatest quantity of inaccurate descriptions in existence (scratch that, C++ is likely worse). As with most of the C programming language, a lot of the behaviour is implementation-defined or even undefined, as you suggest. For example: /* implementation-defined */ #pragma launch_missiles /* undefined */ #define explosion defined #if explosion # pragma launch_missiles #endif This makes a preprocessor /easier/ to implement, because in these cases the implementer can do /whatever she wants/, including doing nothing or starting the missile launch procedure. In the implementation-defined case, the implementor must additionally write the decision down somewhere, i.e. "Upon execution of a #pragma launch_missiles directive, all missiles are launched".

http://megaplanet.org/jean-marie-favre/papers/CPPDenotationalSemantics.pdf

If this paper had criticised the actual C standard as opposed to a working draft, it would have been easier to take it seriously. I find the published standard quite clear about the requirements of a C preprocessor. Nevertheless, assuming that the complaints of the paper remain valid, it appears to boil down to "The C is preprocessor is weird, and one must read its whole specification to understand all of it". It also seems to contain a bit of "The C standard does not precisely describe the GNU C preprocessor". This work is certainly within the scope of a summer project. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)