Loading ...
Sorry, an error occurred while loading the content.

Re: Hot off the press (well hot out of the compiler)

Expand Messages
  • Jim Fougeron
    ... HAHA what a bug report ;P I typed that version# printf with lots of anticipation about beer which was waiting to be drank ;) and thus ly was drunk.
    Message 1 of 33 , Nov 1, 2000
    View Source
    • 0 Attachment
      --- In primeform@egroups.com, "David Broadhurst" <d.broadhurst@o...>
      wrote:
      > PS: Thanks for the early Christmas present:
      >
      > > PFGW Version 20001229_Win_Dev (Beta software, 'caveat utilitor')
      > ^^^^^^^^

      HAHA what a bug report ;P

      I typed that "version# printf" with lots of anticipation about
      beer which was waiting to be drank ;) and thus'ly was drunk.

      Jim.
    • Jim Fougeron
      ... can ... workaround ... fix. No Chris, the bug happens for ANY input expression/number (the stuff shown on the progress indicator) if that expression/number
      Message 33 of 33 , Nov 9, 2000
      View Source
      • 0 Attachment
        --- In primeform@egroups.com, "Chris Nash" <chris_nash@p...> wrote:
        > Hi folks
        >
        > >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
        can
        > tell, it only occurs in N-1 testing mode, and there is no
        workaround
        > other than to use the previous version. Jim's already submitted a
        fix.

        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. I
        > thought I'd got a working (but not necessarily completely-optimal)
        N+1
        > implementation up and running, and had it chewing on quite a few
        > 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 :)

        As I stated to Chris in an offline email, David has now been granted
        the honors as "King" of the beta testers ;) and I think the votes
        will hold.

        > I have no idea how these things happen, but thanks to David for
        > spotting yet another bug before it ever happened!
        >
        > Chris
      Your message has been successfully submitted and would be delivered to recipients shortly.