Take two - CPP: #line semantic changes
Neil Booth
neil@daikokuya.demon.co.uk
Wed Mar 6 11:14:00 GMT 2002
Zack Weinberg wrote:-
> This patch is a revised version of one that was posted last month.
>
> All versions of GCC to date implement #line in a fashion which is
> internally consistent, but incompatible with both the C standard and
> (my limited sample of) other compilers. To be specific, in the form
>
> #line 23 "filename"
>
> the least contrived reading of the standard[1] is that "filename" is a
> true string constant; escape sequences are converted, "\"" names a
> file with one character in its name, '"'. Historically GCC has
> taken the alternate tack of interpreting "filename" the same way it
> would be interpreted as the argument of #include; escape sequences are
> not converted, "\"" is a syntax error.
I still don't agree with conversion of escape sequences (see below)
in #line. I agree it should be done for linemarkers.
> In addition, GCC 3.0's implementation is buggy; it will produce
> mangled .i and/or .s files when the name of the input file, or the
> filename specified in #line, contains control characters.
>
> I'm not hugely interested in sticking to the apparent letter of the
> standard here, since it _can_ be interpreted the other way, and no
> one's objected to existing practice; however, it does turn out to be
> incompatible with at least two other compilers (EDG's front end and
> MSVC -- the latter is interesting since Windows is where one might
> expect \ not being an escape introducer to be desirable). Therefore,
> this patch changes #line to interpret escape sequences.
Seeing your patch, I've done a couple of tests today. EDG does _not_
interpret escapes in #line directives, at least as far as I can tell
it behaves identically to current GCC: Comeau's compiler at
www.comeaucomputing.com/tryitout, with
#line 20 "foo\nbar"
int ;
it gives an error message that refers to file "foo\nbar". This is true
even on the Windows platform.
MSVC++ does indeed interpret the escape sequence as a newline in the
file name. However, their preprocessor has so many issues I'd rather
not hold it up as an example to be followed.
> The behavior of "linemarkers" (# nnn) is also changed by this patch.
> Here the only workable thing to do is convert control characters to
> escape sequences when printing linemarkers, and convert them back when
> they are read in.
Agreed.
> /* Interpret #line command.
> - Note that the filename string (if any) is treated as if it were an
> - include filename. That means no escape handling. */
> + Note that the filename string (if any) is a true string constant
> + (escapes are interpreted), unlike in #line. */
^^^^^ typo?
> - new_file = (const char *) token->val.str.text;
> + new_file = (const char *) dequote_string (pfile, token->val.str.text,
> + token->val.str.len);
This is the part of the patch I don't agree with.
> file it specifies, until something else happens to change that.
> +@var{filename} is interpreted according to the normal rulcvs server: I know nothing about doc/cppinternals.info
> es for a string
Ahem 8-)
Neil.
More information about the Gcc-patches
mailing list