Re: FYI: Adjust @$ for empty reductions

[Paul Eggert]

Akim Demaille <address@hidden> writes:

> The distance between the boundaries of the token returned by yylex
> is yyleng (except when there are newlines of course).

Tabs are another exception.

Another exception can occur with multibyte characters.  In UTF-8 it is
common for the number of bytes to not equal the number of columns.
For example, the UTF-8 representation for most Japanese characters
consumes 3 bytes, but these characters typically consume only 2
columns.

The Bison manual should probably mention all this somewhere, sigh.

>> The Bison manual also uses this tradition in its example, which
>> contains this code:
>>
>>                        printf("Division by zero, l%d,c%d-l%d,c%d",
>>                               @3.first_line, @3.first_column,
>>                               @3.last_line, @3.last_column);
>>
>> Again, this uses last_column as the column of the last character
>> in the location, not the first character after the location.
>
> I don't see that here.  This code does not make the provision that
> location_print did, that's all.

Sorry, I don't follow.  Are you saying the code is buggy?  Or that it
generates consistent but weird output?

As an aside, it would be clearer if the examples were changed to
follow the GNU coding standards for column numbers in error messages:
currently they output stray "l"s and "c"s.

>> I prefer this sort of solution as well; that is why I used it in
>> parse-gram.y.
>
> Actually, I started it.

Sorry, I'd forgotten that.

> I do not agree with the ending boudary issue: it is a non issue.
> They have been implemented differently.  Sometimes they have been
> presented differently, period.

OK, I'm starting to see it now.  (I'm looking forward to an
entertaining reading in NEWS.  :-)