Re: Regression for gdb.pascal/* [Re: [RFA 4/4] Constify parse_linesepc]

[Sergio Durigan Junior <sergiodj@redhat.com>]

On Wednesday, October 16 2013, I wrote:

> On Wednesday, October 16 2013, Jan Kratochvil wrote:
>
>> On Wed, 02 Oct 2013 06:38:28 +0200, Keith Seitz wrote:
>>> All committed. Thank you Sergio and Tom for looking at this!
>>
>> c85cddc51d5d9e4423509a2dc7cf3d9809451b49 is the first bad commit
>> commit c85cddc51d5d9e4423509a2dc7cf3d9809451b49
>> Author: Keith Seitz <keiths@redhat.com>
>> Date:   Wed Oct 2 00:46:06 2013 +0000
>>
>>     Constification of parse_linespec and fallout:
>>     https://sourceware.org/ml/gdb-patches/2013-09/msg01017.html
>>     https://sourceware.org/ml/gdb-patches/2013-09/msg01018.html
>>     https://sourceware.org/ml/gdb-patches/2013-09/msg01019.html
>>     https://sourceware.org/ml/gdb-patches/2013-09/msg01020.html
>
> Thanks for the report.
>
> The problem happens because when yylex is going to parse a number, it
> starts by saving the pointer to the input string in a variable "p", then
> it advances this variable depending on what it finds, and finally it
> updates "lexptr" by using "p".  However, "p" is "tokstart" at the
> beginning of the function, which used to be the same pointer as
> "lexptr", but now it's allocated using "alloca".
>
> I chose to fix this by advancing "p" and "lexptr" by the same amounts
> every time, so that they do not get out of sync (which also makes it
> unnecessary to update "lexptr" in the end).
>
> I ran the failing tests and they pass now.  I am running a regression
> test now, but it will take a long time to complete, so I am sending this
> patch for appreciation first.
>
> OK to apply?

I had a brief chat with Keith, who updated me on this.  According to
him, there are many more places that need to be updated.  He's already
talking to Pierre about this, so probably my patch is not
complete/correct.  Thus, feel free to drop it if it is the case.

Thanks,

-- 
Sergio