Re: [bug-gawk] UNFIELD bug in stable branch

[arnold]

Hi. I'll review.

I bet this fixes the bug Carlo reported a while back. If you have
a chance, please see if it does. If not I'll get to it.

Thank you very much for investigating and coming up with a fix.

Arnold

"Andrew J. Schorr" <address@hidden> wrote:

> On Sun, Jan 22, 2017 at 07:39:22PM -0500, Andrew J. Schorr wrote:
> > On Sun, Jan 22, 2017 at 06:48:31PM -0500, Andrew J. Schorr wrote:
> > > Here's a much simpler version. The master branch correctly prints "apple",
> > > whereas the gawk-4.1-stable branch prints "pear". Ugh.
> > 
> > According to git bisect:
> > 
> > ac7bcb4c8cdc07f974205709616fda91a447c0f1 is the first bad commit
> > commit ac7bcb4c8cdc07f974205709616fda91a447c0f1
> > Author: Arnold D. Robbins <address@hidden>
> > Date:   Mon Nov 17 17:25:05 2014 +0200
> > 
> >     Add unfield code in several spots.
> > 
> > :100644 100644 9910ea72481724aa5b94a7f4c61bb5a36dc74dab 
> > 2901f60e557960a02bb1f3e6a13fb17db44d8a82 M      interpret.h
>
> The attached patch to the UNFIELD macro in interpret.h fixes the bug and 
> passes
> "make check" and "make valgrind-noleak". I basically copied my revised version
> of the UNFIELD macro from the master branch. That being said, I never really
> understood what motivated the previous (buggy) version of UNFIELD in the 
> stable
> branch, so I'm afraid I could be missing a subtle problem. It never made sense
> to me that disabling the FIELD bit could work, but I had the sense that this
> code was never hit. I seem to have found the code sequence that tickles
> that scenario. I think the FIELD bit was getting disabled in Op_store_field or
> Op_store_var.
>
> Arnold -- let me know if you'd like me to commit this along with the new
> test case.
>
> Regards,
> Andy