Re: bison location reporting for potentially-empty list productions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: bison location reporting for potentially-empty list productions
Date: 2012-10-04 15:43:12
Message-ID: 28105.1349365392@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> To produce a really useful cursor for this type of situation I think
> we would have to do something like this:

> #define YYLLOC_DEFAULT(Current, Rhs, N) \
> do { \
> int i;
> (Current) = -1; \
> for (i = 1; i <= (N); i++)
> {
> (Current) = (Rhs)[i]; \
> if ((Current) >= 0)
> break;
> }
> } while (0)

> This is pretty ugly and seems likely to create a visible hit on the
> parser's speed (which is already not that good). I'm not sure it's
> worth it for something that seems to be a corner case --- anyway
> we've not hit it before in six years since the location tracking
> support was added.

After another look at the Bison manual I realized that there's a way to
fix this without making YYLLOC_DEFAULT slower, because that macro only
sets the *default* location for the current nonterminal; the rule action
is allowed to override its location value. So I propose the attached
patch against HEAD. This is a little bit ugly because we have to
remember to put some extra code in productions that have this issue ...
but track record so far suggests that there will be very few of them.

Anyone have an objection, or a better idea?

regards, tom lane

Attachment Content-Type Size
fix-empty-list-location.patch text/x-patch 3.5 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-10-04 16:00:00 Re: Sharing more infrastructure between walsenders and regular backends (was Re: Switching timeline over streaming replication)
Previous Message Gaetano Mendola 2012-10-04 15:36:19 hackers newsgroup hacked ?