Integration SDK 4.10c Errata
Fixes affecting users of the ScriptEase ISDKs

• 4.10c, both ISDK/C and ISDK/Java - latest update: September 29, 2000
  

  For Both ISDK/C and ISDK/Java, version 4.10c

• Null-pointer exception when using _put on global variable
• Error reading pre-compiled floating-points
• Functions not callable after parsing error
• Problems executing pre-compiled code
• incorrect error message for wrong number of parameters
• Invalid line numbers or breakpoints
• Parsing errors
• ISDK incrementing dynamic object
• Using "Delete" Operator On Non-Reference Var
• Changing The Global Object

The Details

For both ISDK/C and ISDK/Java, version 4.10c

• Null-pointer exception when using _put on global variable

  Bug: When trying to assign a value to a member of an undefined variable, and there is an dynamic _put method assigned to the global variable, a null-pointer exception will be thrown. (SE:ISDK/Java 4.10c)

  Fix: In Operator.java at line 323 (in method do_op_structureMember), remove the line which reads:

   orig.VAR_REMOVE_USER(call);

  and in Var.java at line 93 (in method GET_READABLE_VAR), change this line:

   if ( membername==0 )

  to

   if ( VAR_HAS_DATA() )

• Error reading pre-compiled floating-points

  Bug: In SE:ISDK/Java 4.10 floating-point values may not be read correctly from pre-compiled bytecodes (i.e. bytes created with jseCreateCodeTokenBuffer).

  Fix: In TokenDst.java method ReadNumber() change this line
     val = 256*val+buf.at(ByteCount-i-1);
  to
     val = ( val << 8 ) | (buf.at(ByteCount-i-1) & 255);

• ISDK/Java parsing error leaves function in uncallable state

  Bug: In SE:ISDK/Java 4.10 if there is a parsing error while compiling a function that function is left in an uncallable state.

  Fix: The following code change will remove the function if compilation fails. In FunctionParms.java, near the end of method Delete() change this code:

     if ( !lfunc.ResolveVariableNames(pCall) )
  
        pSuccessFlag[0] = false;
  
  

  to this:

     if ( !lfunc.ResolveVariableNames(pCall) )
  
     {
  
        // function failed; so delete the variable that is this function
  
        VarRead funcVar = VarUtil.GetDotNamedVar(call,
  
                 call.session.GlobalVariable,
  
                 call.GetStringTableEntry(GetName()),
  
                 true);
  
        funcVar.VAR_REMOVE_USER(call);
  
        pSuccessFlag[0] = false;
  
     }
  
  

• Problems executing pre-compiled code

  Problem: When executing pre-compiled code, some scripts will run incorrectly or hang.

  Fix: in SECODE.JAVA change this line:

     int ag = AbsoluteGotoFromRelative(This.opcodes,
  
                                       This.opcodes[idx]);
  
  

  to this:

     int ag = AbsoluteGotoFromRelative(This.opcodes,
  
                                       This.opcodes[idx+1]);
  
  

• incorrect error message for wrong number of parameters

  (ISDK/Java 4.10)
  Problem: error message not printing correctly for wrong number of parameters to a function.

  Fix: In srccore/Call.java, line 3474, add the method:

       void Quit(String text,int num,String text2)
  
       {
  
          Error(text,num,text2);
  
       }
  
  

  In srccore/LibraryFunction.java, line 115, changes to:

             call.Quit(TextCore.INVALID_PARAMETER_COUNT,
  
                       VarCount,GetName(call));
  
  

  (This is approximately the 4th line in the Execute() method.)

• Invalid line numbers or breakpoints

  (for ISDK/Java 4.10c)
  Error: When interpreting from source text (instead of from file) the text in the first line is ignored. This can manifest as line numbers being invalid, breakpoints being off, or the script just acting wacky.

  Fix: In the file Source.java, method "Source(Source PrevSB, BytePtr SourceText)", delete these lines:

  
  
    if ( MemoryPtr.cursor > 0 ){
  
       MemoryPtr.shift(-1).setCharAt(0,'\0') ;
  
    }
  
    /* start at line 1 not 0 */
  
    pLine++;
  
  

  and replace these lines:

  
  
    int len = CStringLib.strlen(SourceText)+1 ;
  
    MemoryPtr = new BytePtr( len ) ;
  
    CStringLib.strcpy(MemoryPtr,SourceText);
  
  

  with these:

  
  
    int len = CStringLib.strlen(SourceText)+1+1/*beginning null*/ ;
  
    MemoryPtr = new BytePtr( len ) ;
  
    MemoryPtr.setCharAt(0,'\n');
  
      /* always for first line to be read */
  
    CStringLib.strcpy(MemoryPtr.plus(1),SourceText);
  
  

  
  

• Parsing errors

  Problem: Statements such as (SomeFunction)(); generate a parsing error.

  Fix: In CODE.C function CompileFromText(), "case '('", at about line 389, replace this statement:

  
  
     || EndFunctionCall == Type ) {
  
  

  with this statement:

  
  
     || EndFunctionCall == Type
  
     || EndEvaluationGroup == Type ) {
  
  

  The fix is nearly identical in the Java version of CODE.JAVA.

• ISDK incrementing dynamic object

  Problem: Using the increment or decrement operators on a property of a dynamic object (i.e., and object with _get or _put methods) may result in the variable being replaced by an undefined value. For instance, this script:

  
  
  var foo.x = 0;
  
   printf("foo.x++ = " + foo.x++);
  
   printf(" foo.x = " + foo.x);
  
  

  will print "0 undefined" if foo._get() returns a newly-created, temporary variable.

  Fix:
  in SE:ISDK/C --

  ..is in SECODE.C about 5 lines after the statement:

  
  
   case opPreDecrement:
  
  

  replace:

  
  
  if ( VNumber == lVar->varmem->data.vall.dataType )
  
  

  with:

  
  
   if ( wVar == lVar /* no dynamic obj happening */
  
   && VNumber == lVar->varmem->data.vall.dataType )
  
  

  * * * * *

  Fix:
  in SE:ISDK/Java 4.10c --

  The replacement is similar. In secode.java:

  replace:

  
  
   if ( VNumber == lVar.varmem.dataType )
  
   

  with:

  
  
   if ( wVar == lVar /* no dynamic obj */
  
   && VNumber == lVar.varmem.dataType )
  
  

• Using "Delete" Operator On Non-Reference Var

  Problem: the "delete" operator used on a non-reference variable (e.g. "delete 0", "delete global") will crash the engine.

  Fix:
  for ISDK/C --

  In the do_op_delete() function of OPERATOR.C, after reporting the message BAD_DELETE_VAR replace this line:

  
  
   return NULL;
  
  

  with this:

  
  
   return constructVarRead(call,VBoolean);
  
  

  Fix:
  for ISDK/Java --

  In the do_op_delete() method of Operator.java, after reporting the message BAD_DELETE_VAR, replace this line:

  
  
   return null;
  
  

  with this:

  
  
  return Var.constructVarRead(call,VBoolean);
  
  

• Changing The Global Object

  (In v4.10c for both ISDK/C and ISDK/Java)

  Problem: user can change the global object from a script, rendering the entire script object tree invalid and inevitably leading to a crash. For example, this script, with "global" being the name of the global object, will crash the interpreter, probably in cleanup:

  
  
  global = 4;
  
  

  The solution is to make the global object a Read-Only variable. This can be fixed from within your application, after jseInitializeExternalLink(), by setting the read-only attribute on for the global object.

  Fix: in the core engine for ISDK/C:

  In the NewGlobalVariable() function in UTIL.C add the following statement after "varAddUser(newGlobalVariable);"

  
  
  varSetAttributes(newGlobalVariable,jseReadOnly);
  
  

  = = = = = = =

  Fix: in the core engine for ISDK/Java

  In the NewGlobalVariable() method of Call.java, add the following statement after "newGlobalVariable.SetLvalue(true);"

  
  
   newGlobalVariable.SetAttributes(jseReadOnly);