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

Nick Bowler nbowler at elliptictech.com
Tue Mar 30 17:09:45 EDT 2010


On 19:54 Tue 30 Mar     , Stephen Tetley wrote:
> On 30 March 2010 18:55, Serguey Zefirov <sergueyz at gmail.com> 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/)


More information about the Haskell-Cafe mailing list