#line directives generated incorrectly in win_flex 2.5.37

[David Librik]

When win_flex 2.5.37 generates a .c from a .l file,
it adds #line directives to the .c file to indicate
which lines in the .l file correspond to lines in
the .c file.

Unfortunately, there is a bug: the #line numbers are
incorrect, off by 1, for all lines in the final section
of the .l file.

Simple example:

1. Create a file "ex2.l" with the following code in it.
The line "int num_lines = 0, num_chars = 0;" should be
on the first line of "ex2.l", and therefore the line
"int main ()" should end up on line 8 of "ex2.l":
        int num_lines = 0, num_chars = 0;
%%
\n      ++num_lines; ++num_chars;
.       ++num_chars;

%%
int main ()
        {
        yylex ();
        printf ("There were %d lines and %d characters.\n",
                num_lines, num_chars);
        return 0;
        }

2. Run win_flex 2.5.37 on the file as follows:
win_flex ex2.l

3. Now look at the generated file, "lex.yy.c".  At the end,
you will see:

#line 7 "ex2.l"

int main ()
        {
        yylex ();
        printf ("There were %d lines and %d characters.\n",
                num_lines, num_chars);
        return 0;
        }

The #line directive puts the line "int main ()" on line 9.
(#line 7 "ex2.l" means "Consider the next line to be the
same as line 7 of ex2.l", and there are 2 blank lines
between the "#line" and the "int main".)
But if you look in the original "ex2.l" file, "int main ()"
is on line 8, not 9.

This causes a lot of trouble with debugging and compiler
messages.  You can't step through your lex program in GDB
or Visual Studio; it's always pointing at the wrong line.
Error messages refer to the wrong line of the file.

Note that the #line numbers are correct for the rules, and
for the section before the rules.  Only the section after
the rules has its #line numbers off by one.

[Alex Zhondin]

Thank you David!

I will check and fix it.

Do you know if this bug exists in original flex for linux?

[David Librik]

I don't have flex 2.5.37, but I do have flex 2.5.35 on a NetBSD 6 machine, and it
is there too. So it seems this probably isn't your bug, but something in the flex
original source. Alex, can you tell me how to submit a bug report to the main flex
developers? Thanks!

[David Librik]

AHA! It looks like this bug was found and fixed in flex 2.5.39-6,
on 6-May-2014!

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542482

If you would please do your magic and make a winflexbison based on
the latest flex sources (or at least anything after 2.5.39-6), that
would fix the problem in winflexbison!

[Alex Zhondin]

Hi David!

Thank you for investigation.

I'll update win_flex to the latest version next week (now I'm far from my working pc).

[Alex Zhondin]

Hi David!

I've updated winflexbison package with fix from your link https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542482.

Please check.