[erlang-bugs] Code should not compile
Wed Jul 27 14:16:02 CEST 2011
I get it. It is part of a submission to mochiweb and they raised it as
an error. It was only as I tidied it up that I realised I was no
longer using these macros.
This therefore would have been (but wasn't) a run-time error and not a
On 27 July 2011 12:57, Richard Carlsson <> wrote:
> On 07/27/2011 01:44 AM, Gordon Guthrie wrote:
>> I attach a module and a header file.
>> The module hmac_api_lib.erl has a bug on line 9 - the define is
>> incomplete. It should not compile, but it does.
> It's a preprocessor macro definition - they work this way. The first thing
> that happens (after tokenization) is that the code is split up into "forms"
> - sections that end with a period followed by either whitespace (including
> newlines) or EOF. In your example:
> -define(RFC2116_HT, "\t"
> the form begins with '-' 'define' and ends with 'export_all' ')'.
> After that, the preprocessor recognizes the form as a macro definition and
> binds 'RFC2116_HT' to the token sequence "\t" '-' 'compile' '('
> 'export_all'. The last parentheses is considered part of the -define
> directive, so it's not included. (Remember that it used to be that you could
> even leave out the final parenthesis? It wasn't actually needed, because the
> period+whitespace tells you where the definition ends, but it caused some
> confusion, so the end parenthesis must be there nowadays.)
> It should be possible to make the preprocessor detect this sort of mistake
> in typical cases and at least emit a warning, but in general, macros must
> still be allowed to 1) be spread over multiple lines, 2) contain token
> sequences like '- <atom> (', and 3) not require that the definition body is
> balanced with respect to parentheses and other token pairs like case/end.
> So, it's not a simple matter of changing how the end-of-macro is detected.
> erlang-bugs mailing list
+44 7776 251669
More information about the erlang-bugs