Re: Hot off the press (well hot out of the compiler)
- View Source--- In firstname.lastname@example.org, "David Broadhurst" <d.broadhurst@o...>
> PS: Thanks for the early Christmas present:HAHA what a bug report ;P
> > PFGW Version 20001229_Win_Dev (Beta software, 'caveat utilitor')
I typed that "version# printf" with lots of anticipation about
beer which was waiting to be drank ;) and thus'ly was drunk.
- View Source--- In email@example.com, "Chris Nash" <chris_nash@p...> wrote:
> Hi folkscan
> >This bug has been found and fixed. It was a stupid bug added to
> >this dev version. It did not exist prior to this. It was also
> >a simple 2 line fix. It has to do with the length of the
> >expression (a raw number in this case). It will be fixed in the
> >next release. If this is causing problems for anyone, then I
> >recommend using version 1029 until the next PFGW version. Version
> >2109 is still in the files section if you need it.
> Jim found the bug in no time at all, it's to do with the progress
> string added in the last version, and occurs if the number as it
> appears in the text file is longer than a screen line. As far as I
> tell, it only occurs in N-1 testing mode, and there is noworkaround
> other than to use the previous version. Jim's already submitted afix.
No Chris, the bug happens for ANY input expression/number (the
stuff shown on the progress indicator) if that expression/number
is longer than 70 bytes. The reason why it manifests itself in the
N-1 mode is that the bug is a buffer overflow, and the way the program
links the data, there was a global variable which was being used in
the N-1 mode which was overwritten. A larger overflow would cause
any number of other variables and even code to be overwritten.
My suggestion still is to use 1029 for ANY input number types which
are rather long (greater in size than 69 characters). Run a 20k
number (not a simple expression, but a "straight number) through
and I bet you will see problems, and not just problems in the N-1
code. The bug is a show stopper for this type of number input.
But like Chris stated, it is a trivial fix, and there is no logic
problem with the PFGW software, this was simply a bungle trying to
get a "cleaner" user view.
> David's 103-digit number had another peculiar property as well. IN+1
> thought I'd got a working (but not necessarily completely-optimal)
> implementation up and running, and had it chewing on quite a fewAs I stated to Chris in an offline email, David has now been granted
> testbed numbers for the past 48 hours with no problems.
> Just for the sake of it, I tried David's number, and the darn thing
> locked up on me :)
the honors as "King" of the beta testers ;) and I think the votes
> I have no idea how these things happen, but thanks to David for
> spotting yet another bug before it ever happened!