Comment author: administrator

test/unix.idl from camlidl distribution contains the following:

[---cut---]
quote(C,"
#include <stdlib.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <dirent.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/time.h>
#include <fcntl.h>
...
")
[---cut---]

these #include statements are interpreted by an external preprocessor, which
camlidl calls during .idl compilation and became expanded in the resulting .c
file. Obviously that's not what the programmer expected.

I was under the impression that # directives inside a string literal
must be ignored by an ANSI C preprocessor; this is what gcc does,
however the K&R second edition doesn't seem to guarantee this.

So at least do not use above (wrong) construct in your examples --

it should be written as

[---cut---]
quote(C,"#include <stdlib.h>")

Sounds very reasonable. I'll do that.

Best regards,

• Xavier Leroy

Comment author: administrator

Xavier Leroy Xavier.Leroy@inria.fr writes:

test/unix.idl from camlidl distribution contains the following:

[---cut---]
quote(C,"
#include <stdlib.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <dirent.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/time.h>
#include <fcntl.h>
...
")
[---cut---]

these #include statements are interpreted by an external preprocessor, which
camlidl calls during .idl compilation and became expanded in the resulting .c
file. Obviously that's not what the programmer expected.

I was under the impression that # directives inside a string literal
must be ignored by an ANSI C preprocessor; this is what gcc does,
however the K&R second edition doesn't seem to guarantee this.

Yes, gcc ignores preprocessor directives inside string literals, but msvc
expands them even in ANSI compatibility mode:

[test.c]
"
#define A B
"
A
[end of test.c]

D:\Work\camlidl-test>cpp test.c

1 "test.c"

"
#define A B
"
A

D:\Work\camlidl-test>cl /nologo /E /Za test.c
test.c
#line 1 "test.c"
"

"
B

Probably that's MSVC bug, because ISO C++ standard (don't have an ANSI C
one here) tells that

[---cut---]
2- A preprocessing token is the minimal lexical element of the language in
translation phases 3 through 6. The categories of preprocessing token are:
header names, identifiers, preprocessing numbers, character literals,
string literals, preprocessing-op-or-punc, and single non-white-space
characters that do not lexically match the other preprocessing token
categories.
...
1- A preprocessing directive consists of a sequence of preprocessing
tokens. The first token in the sequence is a # preprocessing token that is
either the first character in the source file (optionally after white space
containing no new-line characters) or that follows white space containing
at least one new-line character. The last token in the sequence is the
first new-line character that follows the first token in the sequence.*
[---cut---]

But anyway it's easier to work around this bug when wait until MS fix it
:-)

Hope to hear from you soon,
Dmitry

Comment author: administrator

Fixed example as suggested. XL, 2001-07-30