Re: #line %foo

[Paul Eggert]

> From: Akim Demaille <address@hidden>
> Date: 12 Nov 2002 10:21:44 +0100
> 
> Even if we want to support %line, we need #line.  This was asked
> *years* ago.

OK, but then we should do the job consistently.  We should accept the
same syntax as C; currently we accept only a restricted subset that
cannot handle " within file names.

More important, a #line directive should have the same effect
independently of whether it occurs in bracketed C code or in the Yacc
grammar.  Currently, #line has one meaning outside C code, and quite a
different meaning within C code: the latter doesn't affect file names
in Bison's diagnostics; the former does.

> |  * The other Bison directives are all free format, but "#line" has a
> |    rigid format: it must start in column 1, it must have exactly one
> |    space after the "line", etc.
> 
> Correct, like #line, not like %line.

OK; but C's #line doesn't need to start in column 1, and it can
contain variable whitespace, comments, backslash-newline, etc.  Surely
Bison's directive should be consistent with C if it uses the same
syntax.

> |  * flex -p -p complains about the regex used for #line, saying that
> |    "^" slows things down a bit.
> 
> Yes, I know this, but what do you suggest?

I guess we can live with it.  Maybe insert a comment.  Too bad we
can't use "\n" rather than "^".

> |  * There is no way for #line to represent a file name containing a
> |    double-quote character.  The usual escapes for file names (used in
> |    the C-langauge #line directive) do not work.
> 
> Wow.  But this is what the standard says, isn't it?

The C standard says that the operand of #line is a C string; it's not
like #include.

> |  * There is no overflow checking if the line number is too large.
> 
> What do you mean?

#line 34324234234234234234234234234234234234234