I observed that
>As has often been pointed out in comp.std.c, there is NOTHING in any C or
>C++ standard to forbid a compiler writer defining the end of line indicator
>to be "end of record, preceded by any number of blanks". There is NO
>requirement whatsoever that the "end of line indicator" be just the physical
>end of record.
Derek M Jones <[EMAIL PROTECTED]> wrote in reply:
True. But the compiler has to handle any strictly conforming program.
Agreed.
I can write a strictly conforming program (using macros and stringizing)
where a backslash followed by blanks, followed by end-of-record occurs.
Let's see it! I've tried to think how it might be done. AH!
preprocessing-token:
header-name
identifier
pp-number
character-constant
string-literal
punctuator
each non-white-space character that cannot be
one of the above*
So
#define bar(x) #x<newline>
#define foo(x) bar(x)
#define fred<space>~\<space><newline>
<newline>
char *x = foo(fred);
=>
char *x = "~\";
[lcc and SPARCompiler cc like this, gcc doesn't.]
But if we change fred to
#define fred<space>~\<newline>
<newline>
then we get
char *x = "~";
A compiler that unconditionally turned this into a line splice
would be faulty.
Well, no. As I've said, a compiler is at liberty to define an end of
line indicator however it wants to. Such a compiler would not "turn
this into a line splice", because it would be a compiler in which blanks
at the end of a line (logically) DID NOT EXIST.
I can find nothing in either C standard that requires a C system to
support blanks at the ends of lines. I therefore deny that the translation
unit above *is* strictly conforming. (Nothing in the C standard requires
a C system to support curly braces, either. Hence trigraphs and digraphs.)
The output of the cc and lcc compilers is arguably incorrect; a \ is
supposed to be inserted before each " or \ in the replacement text of the
parameter. I think it should have been "~\\", not "~\".
The purpose of my reference to the #if macro DR was to point out
that such a macro could not be used by a strictly conforming
program within a #if directive.
The reason why foo(fred) can't be used within an #if is that it yields
a string, and strings can't appear in #if. None of the macro _calls_
involves an embedded newline.
So far, the only way I know of that this can show up is a combination of
- stringizing, and
- the fact that ANY character not otherwise forming part of a token is
allowed as a pp-token.
I think the last rule there is a bad one.
gcc -E produces workable output for this example, but gcc -c refuses
to compile it. I don't think any realistic working code is likely to be
broken by a compiler that handles fixed records this way.
