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