Seem to be a bug related to hard-coded string length.
Patch:
--- scanner.re~ +++ scanner.re @@ -76,7 +76,7 @@ } if (!DFlag) { - out.write((const char*)(tok), (const char*)(&cursor[-7]) - (const char*)(tok)); + out.write((const char*)(tok), (const char*)(&cursor[tok[0] == '%' ? -2 : -7]) - (const char*)(tok)); } tok = cursor; RETURN(Parse);
Please send an example of file on which re2c crashes (I can't reproduce with arbitratry files containing '%{%}')
Which version of re2c you use.
How you invoke re2c.
Thanks in advance!
I see the problem and how your patch fixes it, just want to add a real-world test case.
Hello,
I'm using re2c 0.14.2, built from source using MinGW-w64 tools on Windows.
Actually every file that contains %{ %} can crash re2c on my platform. The simplest one is of course
%{ %}
PS: re2c crashes by producing lots of garbage output followed by a segfault.
Great, thanks. "%{%}" won't make re2c crash on my system, but I can track memory corruption with valgrind.
I cannot apply your patch 'as is' (there's a couple of similar mistakes in scanner.re which should also be fixed by the same patch), but I will come up with a fix soon. Thank you for your work!
Released re2c-0.14.3 with commit that fixes the bug. As you can see, I only slightly changed your patch.
Thanks again!