[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: #line %foo
Re: #line %foo
Tue, 12 Nov 2002 10:07:02 -0800 (PST)
> 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
> | * 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
> | * There is no overflow checking if the line number is too large.
> What do you mean?