Author Topic: EEeeK! I discovered a bug!  (Read 104 times)

MrBcx

  • Administrator
  • Hero Member
  • *****
  • Posts: 538
    • View Profile
EEeeK! I discovered a bug!
« on: July 22, 2020, 09:34:51 AM »
I've been testing a lot of old code against my recent changes.

One of my old programs has the following statement in it:

Code: [Select]
DIM EE AS DOUBLE

which gets wrongly translated as

Code: [Select]
static int     EEasdouble;

WTF?

I tracked the bug all the way back to version 703 released in 2013.


2013/06/26 17:00:00 GMT-5
* Changes to 7.0.2 for 7.0.3
* Wayne Halsdorf
* Fixed bug when output involves a number such as 1.345e-15 (Handled in XParse)


The bug seemed to only affect 4 variables named:

EE
Ee
eE
ee


I'm happy to report that I have smashed the bug! 8)

Robert

  • Sr. Member
  • ****
  • Posts: 449
    • View Profile
Re: EEeeK! I discovered a bug!
« Reply #1 on: July 22, 2020, 11:31:49 AM »
I've been testing a lot of old code against my recent changes.

One of my old programs has the following statement in it:

Code: [Select]
DIM EE AS DOUBLE

which gets wrongly translated as

Code: [Select]
static int     EEasdouble;

WTF?

I tracked the bug all the way back to version 703 released in 2013.


2013/06/26 17:00:00 GMT-5
* Changes to 7.0.2 for 7.0.3
* Wayne Halsdorf
* Fixed bug when output involves a number such as 1.345e-15 (Handled in XParse)


The bug seemed to only affect 4 variables named:

EE
Ee
eE
ee


I'm happy to report that I have smashed the bug! 8)

WOW!. Needle in a haystack luck!

But as Benjamin Franklin said, "Diligence is the mother of good luck."

MrBcx

  • Administrator
  • Hero Member
  • *****
  • Posts: 538
    • View Profile
Re: EEeeK! I discovered a bug!
« Reply #2 on: July 22, 2020, 01:30:41 PM »
It was a faulty (internal) FUNCTION IsNumberEx(a$) that was the culprit.

I rewrote that function today in an easier to understand manner.  Not only does that function serve to identify whether its argument is an integer, floating point, or scientific notation but I learned (the hard way) that it's also used to validate SUB and FUNCTION names.

My new version doesn't guarantee, for example, that a scientific notation number is absolutely valid, only that its characters and their counts appear to conform to the general rules of what a SN should be.  I'm still testing all the changes but it's all looking pretty swell at this moment.

Code: [Select]
FUNCTION IsNumberEx (a$)
  DIM RAW i,HasDigit, HasE, HasMinus, HasPlus, HasDecimal, HasInvalid
  i = HasDigit = HasE = HasMinus = HasPlus = HasDecimal = 0

  IF NOT *a THEN EXIT FUNCTION    ' Handle null argument
  '***********************************************************
  ' Rules of scientific notation:
  '   The base is always 10
  '   The exponent is a non-zero integer
  '   The ABS value of the coefficient is >=1 and <10
  '   The coefficient carries the sign (+ or -)
  '   The mantissa carries the significant digits
  ' Rules for this function
  '   Can only have these characters: -+.0123456789eE
  '   Must have at least 1 digit
  '   Only 1 "E" (case doesn't matter)
  '   No more than 2 plus signs
  '   No more than 2 minus signs
  '   No more than 1 decimal point
  '***********************************************************
  WHILE a[i]
    HasInvalid = 1        ' Assume every char is INVALID

    IF (a[i]>47 AND a[i]<59) THEN
      INCR HasDigit      ' 0123456789
      HasInvalid = 0
    END IF

    IF a[i]=43 THEN
      INCR HasPlus        '  +
      HasInvalid = 0
    END IF

    IF a[i]=45 THEN
      INCR HasMinus       '  -
      HasInvalid = 0
    END IF

    IF a[i]=46 THEN
      INCR HasDecimal     '  .
      HasInvalid = 0
    END IF

    IF (a[i]=69 OR a[i]=101) THEN
      INCR HasE           ' e or E
      HasInvalid = 0
    END IF
   
    IF HasInvalid THEN EXIT FUNCTION
    i++
  WEND

  FUNCTION = (HasDigit > 0) AND (HasE <2) AND (HasPlus <3) AND (HasMinus <3) AND (HasDecimal <2)
END FUNCTION ' IsNumberEx