bug-gawk
[Top][All Lists]
Advanced

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

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


From: arnold
Subject: Re: [bug-gawk] UNFIELD bug in stable branch
Date: Mon, 23 Jan 2017 08:10:33 -0700
User-agent: Heirloom mailx 12.4 7/29/08

Wow. I'm really, really sorry that this cost you some much time
and trouble.  Please accept my apologies.

I do still have the files for Carlo. I'll put them where you can
get to them later, I'm on a train at the moment... :-)

Thanks,

Arnold

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

> 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



reply via email to

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