cpp and compliance to C99

[Dave Brolley]

Thomas Pornin wrote:

> Hello,
>
> I have downloaded and tried the cpp included in the last egcs snapshot
> (egcs-20001009) and I have encountered some problems.
>
> The host/build/target machine is an Alpha ev56 running Linux (RedHat 5.1,
> somehow modified). The compiler used is gcc-2.95.2 (but egcs is supposed
> to recompile itself, I think), binutils are 2.9.1 (with BFD 2.9.1.0.4),
> libc is the GNU libc 2.0.7. The compilation was performed with only
> a --prefix as option to configure, and a "make bootstrap" followed by
> a "make install" (GNU make 3.76.1).
>
> On the following code:
> #define a(x) b
> #define b(x) a(x)
> a(a)(a)(a)
>
> the cpp gives the following result:
> b(a)

In my interpretation, this is correct since by the time we've done

a(a)(a)(a)-->b(a)(a)-->a(a)(a)

the tokens introduced by the original a(a) [namely b] have been consumed. a
is therefore available for replacement again.
We then do   a(a)(a)-->b(a)  and stop since  b was introduced by the a(a)
which was introduced by b(a)

>
>
> which seems wrong to me (it performs one extra macro replacement, which
> should not have been done according to the nesting macro rule). It should
> have given: a(a)(a)
>
> On the following code:
> #define a(x) b(
> #define b(x) a(
> a(a)x)x)
>
> the cpp gives the following result:
> b

I think this should yield  a(a)x)x)-->b(x)x)-->a(x)-->b(

For the same reason. By the time a(x) is examined, the tokens introduced by
the original (a) [ namely b( ] have been consumed. To state it another way,
if rescanning of the tokens introduced by a macro 'a' proceeds past the end
of those tokens, then 'a' becomes available again.

> which seems equally wrong (it should have given: a(x)).
>
> I might be completely wrong myself about the interpretation of the
> standard, but I have also another problem, which is definitely a bug:
> on the second example, "cpp -traditional" gives this:
>
> vk.c:4: unterminated macro call
> cpp: Internal error: Segmentation fault (program tradcpp0)
> Please submit a full bug report.
>
> Please note that this is on a 3-line file, therefore without any line
> number 4.

This is obviously a bug.

Dave