Non-compiled source text?
Lars Henrik Mathiesen
thorinn at rimfaxe.diku.dk
Wed Dec 19 08:49:10 AEST 1990
bhoughto at pima.intel.com (Blair P. Houghton) writes:
>>minow at mountn.dec.com (Martin Minow) writes:
>>> #if 0
>>> this doesn't work
>>> #endif
>However, the line
> this doesn't work
>contains a single-quote character beginning a
>character constant that contains a newline,
>in violation of the definition of a character constant.
>The relevant citation is (ANSI X3.159-1989, section
>3.1.3.4, p. 29, ll. 10-19).
>Specifically, line 18 prohibits newlines.
Agreed, character constants can't contain newlines. Therefore, the
single-quote properly falls within the category of preprocessing-token
mentioned by another poster: "Each non-white-space character that
cannot be one of the above" (``the above'' are header-name,
identifier, pp-number, character-constant, string-literal, operator
and punctuator). The behaviour when that happens to a single- or
double-quote is explicitly undefined.
Because the behaviour is undefined, a conforming implementation might
choose to allow newlines in character-constants. But since it violates
the syntax rule you quote, a diagnostic must be given anyway.
But a conforming implementation might also choose to make the
single-quote into a pp-token on its own. In the current example, it
will then be skipped in translation phase 4. If it was not,
translation phase 7 would attempt to convert it to a token, and the
constraint of section 3.1 would be violated, causing a diagnostic.
(This behaviour adds some complexity to the scanner, so I don't expect
to see many compilers implementing it.)
--
Lars Mathiesen, DIKU, U of Copenhagen, Denmark [uunet!]mcsun!diku!thorinn
Institute of Datalogy -- we're scientists, not engineers. thorinn at diku.dk
More information about the Comp.lang.c
mailing list