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

[Andrew J. Schorr]

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

unfield.patch
Description: Text document