warning: '/*' within comment

[Lars Henrik Mathiesen]

martin at mwtech.UUCP (Martin Weitzel) writes:
>Now: Is it "required", "unacceptable" or a "quality of implementation
>     issue", that such a sequence of characters in ignored parts of
>     the source makes the whole program not to compile?

The compiler must behave as if the ignored parts were parsed into
proprocessing tokens. A conforming compiler must produce at least one
diagnostic message for a program that violates a syntax rule or a
constraint in the standard. The syntax states that a character or
string literal does not contain newline characters.

On the other hand, the compiler could just say "non-conforming syntax
used" once and let end-of-line close the literal; that would be an
extension to the syntax. It might alternatively allow multiline
literals; that would perhaps be better quality of implementation, but
it would still have to warn about it.

Strictly speaking, a conforming preprocessor will not be able to find
a ``real'' literal on a line with only one quote character. In that
case, the quote falls into the same category of preprocessing token as
$, @, etc., but with undefined behaviour. It is actually this
undefined behaviour which allows the compiler to find a ``nonreal''
literal instead. But I wonder if it will also allow the preprocessor
to throw the quote away with no message? In any case, it may just let
the pptoken be; if it is ever converted to a token, an error will
occur; but ignored parts are never converted. (Note: This is according
to the MAY 88 draft; it may have changed). But I don't think anybody
will do a lexer like that: When they get to end-of-line with an
unclosed literal, they'd have to go back and rescan for comment starts
and the other quote char. If they did, their (conforming) compiler
might accept the following (conforming, but not strictly conforming)
fragment _without_error_messages_:

#define Q '
#define CTRL(a) (Q##a##Q&037)
	putchar(CTRL(g));

Somebody please tell me that the final standard rules this out. (I
know that it doesn't require it; there are at least two undefined's
and an interpretation issue in here).

--
Lars Mathiesen, DIKU, U of Copenhagen, Denmark      [uunet!]mcsun!diku!thorinn
Institute of Datalogy -- we're scientists, not engineers.      thorinn at diku.dk