[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Andrew J. Schorr
Subject: Re: [bug-gawk] UNFIELD bug in stable branch
Date: Sun, 22 Jan 2017 20:05:13 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

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

Arnold -- let me know if you'd like me to commit this along with the new
test case.


Attachment: unfield.patch
Description: Text document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]