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

[Andrew J. Schorr]

Hi,

On Mon, Jan 23, 2017 at 07:11:42AM -0700, address@hidden wrote:
> Hi. I'll review.

Thanks.

> 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.

He seems to have deleted the branch that demonstrates the bug:

bash-4.2$ git clone https://github.com/CarloWood/Firmware.git
Cloning into 'Firmware'...
remote: Counting objects: 198439, done.
remote: Total 198439 (delta 0), reused 0 (delta 0), pack-reused 198439
Receiving objects: 100% (198439/198439), 80.61 MiB | 7.08 MiB/s, done.
Resolving deltas: 100% (147746/147746), done.
bash-4.2$ cd Firmware
bash-4.2$ git checkout cw_fix_headers
error: pathspec 'cw_fix_headers' did not match any file(s) known to git.

I don't have a copy saved; do you? Should we ask him to make it available
again?

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

It cost me at least 5 hours yesterday. I had just completed an O/S conversion
from Fedora to CentOS when I noticed that a complicated script was
malfunctioning. It turned out that on the old O/S, it was using an old copy of
xgawk 3.1.6.  After upgrading to gawk 4.1.x, it no longer worked. What a
nightmare. I hope the fix is correct, since I already put it into production on
my network. I don't see how disabling the FIELD bit can be correct...

Regards,
Andy

> "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
> 

-- 
Andrew Schorr                      e-mail: address@hidden
Telemetry Investments, L.L.C.      phone:  917-305-1748
545 Fifth Ave, Suite 1108          fax:    212-425-5550
New York, NY 10017-3630