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