Re: #line %foo

[Akim Demaille]

Hi Paul!

| I have some qualms about that patch, for the following reasons:
|
|  * #line isn't documented.

Yes, I know.  I like letting things live for a while for the wild
people, and then documenting it.  I do not plan to keep this secret,
in particular since it's NEWS'd.

|  * The other Bison directives all begin with "%", but "#line" begins
|  with "#".

Even if we want to support %line, we need #line.  This was asked
*years* ago.

|  * 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.

|  * #line affects the output file name.  For example, if the last #line
|    directive is `#line 100 "foo"', then the output of is placed into
|    foo.tab.h and foo.tab.c.  I don't think this is desirable.

I agree.  This is why there is now grammar_file and current_file.  It
no longer happens.

| Smaller points:
| 
|  * 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?

|  * 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?  I never had any
problems using \ in file names up to now.

|  * There is no overflow checking if the line number is too large.

What do you mean?

|  * The output sometimes uses the line number of #line combined with
|    the original input file name.  E.g. if the input file foo.y contains
|    this:
| 
|       %union
|       #line 89 "bar.y"
|       {
| 
|    then the output looks like this:
|     
|       #line 89 "foo.y"
|       typedef union {
| 
|    The "foo.y" is bogus; it should be "bar.y".

This is a known issue.  Actually for months there is an item in TODO
about this.

| That patch looks like a quick hack that was intended for a specific
| purpose.  Can you say what the purpose was?  Perhaps there's a
| different way to do it that doesn't involve adding #line support
| specifically to Bison.

I fail to understand your point.  I'm dead sure we can imagine
situations in which this can cause problems.  Nevertheless, I'm not
sure there is actual code which trigger it.  In addition, as it's a
new feature, people will not start depending on it.


----------------------------------------------------------------------

From: François Pinard <address@hidden>
Subject: Bison and #line in *input*
To: Akim Demaille <address@hidden>
X-Sent: 2 years, 24 weeks, 3 days, 7 hours, 43 minutes, 57 seconds ago

Bonjour, Akim.  Je classe de vieux messages.

Voici une suggestion pour Bison.  Richard avait dit qu'il était d'accord,
si je faisais le travail.  Je n'ai pas fait le travail, mais la suggestion
demeure bonne malgré tout, et je te la transmets, puis je l'oublie jusqu'au
moment où je trébucherai à nouveau sur le besoin :-).

From: pinard (Francois Pinard)
Subject: Bison and #line in *input*
To: address@hidden
X-Sent: 9 years, 40 weeks, 4 days, 5 hours, 24 minutes, 55 seconds ago
Reply-To: address@hidden

Bison generates #line directives in the produced parser.  It sometimes
happen that Bison input is itself produced by tools which produce
#line directives (like m4 or ansi2knr).  It would be nice if Bison was
recognizing these lines and obeying them.

For reference, I'm using GNU bison 1.19.
----------



-- 
François Pinard   http://www.iro.umontreal.ca/~pinard