Problem: Compiling large scripts takes an extremely long time.

Fix: Around line 153 in Loclfunc.jsrc, in the nextToken() method, find this line:

   tok_alloced += 50;

and change it to

   tok_alloced *= 2;

• terminating execution from within a "try" block can cause memory leaks
  (for ISDK/Java 4.30e)
  
  Bug: If execution is terminated while a script is within a try block, such as if the mayIContinue() callback function returns False or by calling jseLibSetExitFlag(), then some allocated memory will not be released.
  
  Fix: in Call.jsrc, in method delete() of the Call class, add this line to the end of the method (just before the 'call = null;' line) at around line 3396:

• RegExp.prototype._class wrong
  (for ISDK/Java 4.30e)

Bug: RegExp.prototype._class should be defined as "RegExp" but is instead defined as the number NaN.

Fix: In Libs/ECMAlib.java at about line 941, replace this line:

   Jselib.JSE_VARSTRING( PROTOCLASS_PROPERTIES, REGEXP_PROPERTY, jseDontEnum),

with this:

   Jselib.JSE_VARSTRING( PROTOCLASS_PROPERTIES, "\"RegExp\"", jseDontEnum),

 

• Object comparisons with wrong hint - Date comparisons fail
  (for ISDK/Java 4.30d)
  
  Bug: Object comparison (<, <=, >, >=) are not correctly following the hint
  logic specified in section 11.8.5 (The Abstract Relational Comparison Algorithm) of the ECMAScript specification. When objects are converted to a primitive value for comparison they should be give "hint Number". This would only show up as a problem for any object that does not have number as its default primitive; the Date object is such an example, and so the following test fails for the date object because it is comparing as a string (the default Date primitive type instead of as a Number (the hint type for comparison).

  Fix: In VarUtil.jsrc, method ECMACompareLess(), change the first two instances of this code (lines 775 and 783):

   convert(call,tmp,jseToPrimitive);

to:

   convertToPrimitive(call,tmp,VNumber); 

• ToNumber() returns incorrect values for "+" and "-"
  (for ISDK/Java 4.30d)
  

Bug: When ToNumber() is called with either "+" or "-" as its argument, the return value should be NaN. Instead, ToNumber() is returning Infinity and -Infinity, respectively.

Fix: In VarUtil.jsrc, method convertStringToNumber, around line 1404, change this line of code:

   if ( lenParsed == lenStr ) 

to:

   if ( lenParsed == lenStr && lenStr != 1 )

• toString(radix) not returing correct value for 0
  (for ISDK/Java 4.30d)

The following simple script should return "0", but does is not:

   var z = (0).toString(10);

Fix: In ECMAlib.java, at the beginning of the method EcmaNumberToStringWithRadix(), insert the following code:

   if( val == 0 )
   {
      buf[0] = "0";
      return;
   }

                              

• toString on functions concatenates some indentifiers
  (for ISDK/Java 4.30d)

Bug: When a function is being converted to a string, a required space may not be displayed after some variables. For example, this code:

   function blah()
   {
      for (var prop in obj);
   }
   display("" + blah);

may produce this output (note that "prop" and "in" have become concatenated):

   function blah()
   {
      for (var propin obj);
   }
                

Fix: Many changes are required to fix this and related problems. Upgrade to 4.30.

• eval does not propogate the "this" of its caller
  (for ISDK/Java 4.30d)

Problem: eval() does not propogate the 'this' of its caller.

Fix: In ECMAlib.java, in the method eval(), change the reference to JSE_INTERPRET_KEEPTHIS in the call to jseInterpret() to JSE_INTERPRET_PARENTTHIS.

In JseInterpretMethod.jsrc, add these lines:

/* Use the 'this' variable from the calling function */
public static final int JSE_INTERPRET_PARENTTHIS = 0x100;

In Call.jsrc, near line 3122, there is a call to RunCompiledCode(), change it to this:

   {
      seObject this_obj = null;
   
      if ( (HowToInterpret&JSE_INTERPRET_KEEPTHIS)!=0 &&
            frameptr != -1 )
      {     
         this_obj = GET_OBJECT(Global.stack[frameptr-(THIS_OFFSET+num_args)]);
      }
      if ( this_obj==null &&
           (HowToInterpret&JSE_INTERPRET_PARENTTHIS)!=0 )
      {
         if( frameptr!=-1 )
         {
            int old_frame;
            int old_num_args;
      
            old_num_args = GET_STORAGE_LONG(OLD_ARGS(this));
            old_frame = GET_STORAGE_LONG(OLD_FRAME(this));        
         
            if( old_frame != -1 )
            {
               this_obj = GET_OBJECT(Global.stack[old_frame-(THIS_OFFSET+old_num_args)]);
            }
         }
      }
      if( this_obj==null )
      {
         this_obj = InterpretCall.GLOBAL();
      }
      InterpretCall.RunCompiledCode( argc, argv, CallMain,this_obj,
                                     HowToInterpret);
   }

 

 

• static Array initializer is not instanceof Object
  (for ISDK/Java 4.30d)

Bug: When an Array object is initialized with a static Array Initialiser, as in this code:

   var foo = [ 1, 2, 3 ];

it is recognized as "instanceof Array" but is not recognized as "instanceof Object".

Fix: In Secode.jsrc, method interpret(), "case seCodeVal.instanceOf:", at about line 5797 is this comment:

   /* at any rate, this is the last chance. */

to fix this bug, insert the following code ahead of the comment, so it reads:

   /* finally. all objects inherit from Object */
   else if (call.ObjectPrototype ==
            functionPrototype.obj_val)
      result = true;
   /* at any rate, this is the last chance. */

• empty Object initializer creates an Array object; should be an Object object
  (for ISDK/Java 4.30d)

Bug: When an object is initialized with the empty set, as in this code:

   var foo = { };

it is initialized as a type Array object, although it should be an Object object.

Fix: In Secode.jsrc, class secompile, method Object(), at about line 3646, change this line:

   if ( t[0].type != ':' )

to this:

   if ( t[0].type != ':' && token.type != '}' )
                                 

• "continue" within "switch" statement jumps to wrong condition
  (for ISDK/Java 4.30d)

Bug: The "continue" statement, when within a "switch" block, will associate its condition with the "switch" statement instead of the enclosing loop.

Fix: In Secode.jsrc, around line 682, add this to the "loopTracker" class:

   boolean is_switch;

at line 3172, in the secompile class, find the newLoop() method, and change its signature to this:

   void newLoop( gotoItem label, boolean is_switch )

in Secode.jsrc, all calls to newLoop() get a second false parameter, except for the one in the Switch() method of the secompile class. That ones get true for its second parameter.

Then, in Secode.jsrc, change the newLoop() method's body to look like this:

   void newLoop( gotoItem label, boolean is_switch ) 
   { 
      loopTracker t = new loopTracker(); 
      t.next = loopTrack; 
      loopTrack = t; 
      t.is_switch = is_switch;
      if ( label != null ) 
         label.loop = t; 
   }

and at line 725 of Secode.jsrc, in the loopTracker class, change the method addContinue to this:

   void addContinue( int addr ) 
   { 
      if ( continuesUsed >= continuesAlloced ) 
      { 
         continuesAlloced += 10; 
         int[] tmp = new int[continuesAlloced]; 
         if( continues != null ) 
            System.arraycopy( continues, 0, tmp, 0, continues.length ); 
         continues = tmp;
      }
      continues[continuesUsed++] = addr;
   }

and finally, in Secode.jsrc, in the Statement() method of the secompile class, within the "case seTokVal.seTokContinue:", around line 1911, change this code:

   it = this.gotoTrack.labels[x].loop;
   if ( it == null )

to:

   it = this.gotoTrack.labels[x].loop;
   if ( it == null || (it.is_switch && !isbreak) )
                              

• Floating point numbers not written correctly in jseCreateCodeTokenBuffer
  (for ISDK/Java 4.30d)

  Problem: When creating tokens with jseCreateCodeTokenBuffer, floating point numbers are written incorrectly.

  Fix: In Token.jsrc, function writeNumber(), at line 248 change this line:

if ( (double)n == n )

to:

if ( (double)n32 = n )

• Floating point numbers not read correctly when interpreting from token buffer
  (for ISDK/Java 4.30d)

  Problem: When interpreting from a precompiled token buffer, floating point numbers will not be read correctly.

  Fix: In Token.jsrc, function readNumber_fromNumber(), at line 516 change this line:

  return (double)val;

  to:

  return Double.longBitsToDouble(val);

• Scripts interpreted from a token buffer may display erratic behavior
  (for ISDK/Java 4.30d)

  Problem: When interpreting from a token buffer, goto labels may become all messed up.

  Fix: In Token.jsrc, function AbsoluteGotoFromRelative(), at line 464 change this line:

  for ( c = 0; 0 != opcodes[RelativeGoto--]; c++ )

  to:

  
  for ( c = 0; 0 != RelativeGoto--; c++ )

• Some characters not read correctly when interpreting from a token buffer
  (for ISDK/Java 4.30d)

  Problem: When interpreting from a token buffer, some characters may be read back incorrectly.

  Fix: In Token.jsrc, function readString(), at line 556 change this block of code:

  for ( i = 0; i < len; i++ )
  {
     char c;
     c = (char)(readByte() | (readByte()<<8));
     str.append( c );
  }

  to:

  for ( i = 0; i < len; i++ )
  {
     char c;
  
     byte b1 = readByte();
     byte b2 = readByte();
  
     byte[] tmp = { b1, b2 };
     c = new String(tmp,0,2).charAt(0);
  
     str.append( c );
  }
  
  

for 4.30a --

• Continue statement in do/while skips while
  (for ISDK/Java 4.30a)

  Problem: continue used in a do/while loop not doing the while condition test, always going to top of loop

  Fix: In srccore/Secode.java function Do(), at the top of the function (about line 2028 ) add this new local variable:

int cont_addr;

In the middle of the function, right before this existing line (line 2051):

addItem( seCodeVal.seContinueFunc, prevLineNumber );

add:

cont_addr = currentItem();

finally, at the bottom of the function, change this line (line 2068):

endLoop( currentItem(), top_of_loop, label );

to:

endLoop( currentItem(), cont_addr, label );

• Variables not being popped off of the stack properly
  (for ISDK/Java 4.30a)

  Problem: When compiling functions, some variables were not being popped off of the stack properly.

  Fix: In srccore/Secode.java, function function() around line 2815, find the following code:

  /* Create a constant for it. */
  newfunc = new LocalFunction( call, name, cfunction, var );
  i = locfunc.createConstant( call, var );
  
  
  if ( !literal )
  
  {
     j = locfunc.addLocal( call, name );
     locfunc.VarFunc[j] = i;
  }
  
  
  call.STACK_POP();

  and remove the call to STACK_POP(); At the end of the same function, find the following code (around line 2890):

  return success;

  and replace it with:

  call.STACK_POP();
  return success;

   

• Error when subtracting C-Strings
  (for ISDK/Java 4.30a)

  Problem: A NullPointer Exception occurs when subtracting C-strings

  Fix: In srccore/Secode.java in the case statement for seCodeVal.seSubtract (around line 5785), change this line:

  if ( lhs2.GET_OBJECT() != rhs.GET_OBJECT() ) 

  to:

  if ( lhs2.GET_STRING() != rhs.GET_STRING() )

• jseSetSharedData() not adding data correctly
  (for ISDK/Java 4.30a)

  Problem: After the first call to jseSetSharedData(), subsequent calls write over previous data.

  Fix: In srccore/Call.java in jseSetSharedData, find the following section of code (around line 5349):

  newNode = new sharedDataNode();
  newNode.next = Global.sharedDataList;
  newNode = new sharedDataNode();

  and remove the second call to sharedDataNode's constructor.

• NullPointer exception when using jseCallStackInfo()
  (for ISDK/Java 4.30a)

  Problem: A NullPointer exception is thrown when using jseCallStackInfo()

  Fix: In srccore/Call.java function jseCallStackInfo() (around line 5140), find the following line:

  num_args = Global.stack[fptr - ARGS_OFFSET].GET_STORAGE_LONG();

  and replace it with this line:

  nargs = Global.stack[fptr - ARGS_OFFSET].GET_STORAGE_LONG();

   

• Error when moving backwards in C-string
  (for ISDK/Java 4.30a)

  Problem: An ArrayIndexOutOfBounds Exception is thrown when attempting to move back in a C-string

  Fix: In srccore/seVar.java there is a function getValue with the following signture: final boolean getValue( Call call, int mem, seVar dest ). Near the end of this function, find this section of code (around line 990):

  String data = getData( call );
  /* will go back, but we've verified there is enough stuff to read from */
  INIT_NUMBER(dest, (double)data.charAt( loc ) );
  

  change this section to this:

  int off = getDataOffset( call );
  
  seString data = GET_STRING();
  
  INIT_NUMBER(dest, (double)data.data.charAt( off+loc ) );

  You will also have to add the function getDataOffset to the seVar class. The source can be found at ftp://ftp.nombas.com/pub/isdkeval/se430/dataOffset.txt.