ScriptEase ISDK DevSpace


	Nombas > SE:ISDK DevSpace > Errata > Core Interpreter Errata

Core Interpreter Errata
Errors in the Core Interpreter will affect all products

4.10b
4.10a
4.03c
4.03b
4.03a
4.02
4.01

Version 4.10B errata (may apply to earlier versions)

Line numbering information is lost for error reports and for debugging when literal strings are concatenated between lines, as in this example:
   print("I "
         " like "); print("Ike");
The script workaround is to use the plus operator (+) to concatenate multi-line string literals. The fix in the source code is at about line 387 of CODE.C after the call to CompleStringToken() to replace this line:
  Type = pushValue;
with this code:
  codeSetType(code,pushValue);
  while ( code->NextCodeCard != codeNext(code) )
    code = code->NextCodeCard;
  Type = codeGetType(code);
A line containing an assignment, not terminated with a semi-colon, and followed by a blank line leads to no assignment being made. Fixed in 4.10C. The workaround is to terminate lines with semi-colons, or for ISDK users to put this line at the top of SECODE.C:
#define JSE_PEEPHOLE_OPTIMIZER 0
Addition and subtraction is incorrect on individual elements of C-like strings and buffers. For example, if foo is a string in a cfunction or is a buffer then 0+foo[0] will not produce the correct results. This is fixed in 4.10C. The fix, which is only needed if buffers or C-behavior are enabled, is in do_add_or_subtract() in OPERATOR.C to remove the if block following this comment: /* This is the most common...
ToString() and ToBuffer() may crash on systems unable to allocate zero bytes. This may also affect other calls that perform conversions to string or buffer types. This is fixed in 4.10c. The simplest workaround is to add 1 to the size of temporary xxxMalloc() calls in convert_var_ToBuffer() and convert_var_ToString() in VARUTIL.C

Version 4.10A errata (may apply to earlier versions)

Array Sort may sort incorrectly if the script-supplied sort comparison function returns floating-point non-integer values. The problems arises from the cast to an integer after the jseCallFunction() is made in array_sort_func(). This is fixed in 4.10b. The workaround is to call jseGetNumber() on the script function result, and return -1, 0, or 1, depending whether the result is less-than, equal-to, or greater-than 0.0.

Version 4.03C errata (may apply to earlier versions)

Invalid boolean value determined for NaN and Undefined variables; i.e., the result is true when it should be false, and vice versa. This is fixed in 4.10. The interpreter engine source code fix in SECODE.C, function secodeInterpret(), for the case gotoFalse: case goto True: is to change similar code to the following:
The arguments object is incorrectly freed after a function executes. It is only free if the function uses its own name, such as "foo.a" within the function. This problem only manifests itself if a function uses the arguments object but does not use its own name. This will cause a memory leak in most functions, though it will crash when within a dynamic function such as "_put".

Script fix: To get around this, simply reference the function's name within any function that uses the arguments object. For example:
Source code fix: In functiondoCall (FUNCTION.C line 338), make the cleanup that used to only happen if Func_UsesItsName was set apply to both that and the FuncUsesArguments flag:
Strings may not be treated as a number in subtraction. For example ("6" - 3) will not result in 3. This will be fixed with release 4.10. The script fix is to convert strings to numbers before subtracting. The source code fix is in OPERATOR.C near line 235 is:
Some instances of the _prototype property do not have their DontEnum property set, and so will show up where not expected in for(...in...) statements. This is fixed in 4.10. The fix is to set the jseDontEnum property wherever a member of name prototype_entry is created with varCreateMember(). For example, in SECODE.C the varSetAttributes() line was added at line 825:
This fix must be applied twice in SECODE.C & SECODE.JAVA (lines 825 & 840), once in FUNCTION.C & FUNCTION.JAVA (line 297), and once in VARREAD.C & VARREAD.JAVA (line 561).
If an object has both a valueOf() and a toString() property, then toString() is always called by default. This is fixed in 4.10. To fix in 4.03 file VARUTIL.C implement the following differences:
  177c177
  < convert_var_ToPrimitive(struct Call *call,VarRead *SourceVar)
  > convert_var_ToPrimitive(struct Call *call,VarRead *SourceVar,
                            jsebool hintstring)
  184c184
  < new_var = varDefaultValue(SourceVar,call,True);
  > new_var = varDefaultValue(SourceVar,call,hintstring);
  375c375
  < VarRead *vartemp = convert_var(call,SourceVar,jseToPrimitive);
  > VarRead *vartemp = convert_var_ToPrimitive(call,SourceVar,
                                               True);
  616c616
  < new_var = convert_var_ToPrimitive(call,SourceVar);
  > new_var = convert_var_ToPrimitive(call,SourceVar,False);
  1642c1642
  < vy = convert_var_ToPrimitive(call,vy);
  > vy = convert_var_ToPrimitive(call,vy,tx!=VNumber);
  1650c1650
  < vx = convert_var_ToPrimitive(call,vx);
  > vx = convert_var_ToPrimitive(call,vx,ty!=VNumber);
Increment and Decrement operators do not work properly on strings. For example, this script:
will make foo be the string "401" instead of the number 41. This is correct in release 4.10. The fix is to move function do_op_crement() from CREMENT.C to OPERATOR.C, and to use this code for all except a jseTypeBuffer:
! (NOT) operator gives wrong results on objects and strings. Will evaluate object as a number and peform operation on object, but instead should always return false for all objects. Fixed in 4.10. A fix to 4.03C is to change do_op_boolNot() in OPERATOR.C to this code:

Version 4.03B errata (may apply to earlier versions)

There is an error in tokenizing source code if JSE_TYPE_BUFFER is not defined as 1. This can be correct in the VARUTIL.C source code by adjusting the #ifdefs in the TokenWriteVar() function, and will be so corrected in 4.03C.
If security is enabled, and you initialize a security script, the global code (i.e. those lines of script which are not within any function) is ovewritten. This will be fixed in 4.03C. Contact us if you need the fix integrated before that release.
This problem is relevant to CreateConvertedVariable, ConvertVariable, and any other routine which calls convert_var(). If these routines are called with a Number, and are supposed to convert it to a string, then some problems can occur because the string conversion only preserves six decimal places of accuracy. This presents problems with big integers and accurate floating point values. This will be fixed in 4.03C to preserve many more decimal places and to lop off the trailing zeros in floating point numbers as it should. With 4.03C the function will behave in the same manner as Number.toString().
"11" == 11 compares correctly, but 11=="11" does not. This will be corrected with 4.03C. Those with source code can correct this problem by editing VARUTIL.C and changing line 803 from
if( yType==VNumber || yType==VString || yType==VBoolean )
to
if( yType==VNumber || (yType==VString && xType==VObject) || yType==VBoolean )
Converting a function to text does not work correctly if there is a left bracket ([) operator in the function. This can be fixed (and will be fixed in 4.03C) by adding the following case to the switch() statement at line 517 in the file FUNCTION.C:
A negative sign (-) is misinterpreted if it is the first parameters to an object's method. This will be fixed with 4.03C. An example of this error would be the following statement:
When using the jseOptReqVarKeyword flag, conditional compilation flags such as #ifdef can report that the variable is undefined. This options is fixed for 4.03C, where jseOptReqVarKeyword is temporarily suspended during execution of the conditional compilation.
Strings can convert to numbers incorrectly in instances such as if "123abc"==123. This is corrected in 4.03C.
-Infinity != "-Infinity". This is corrected in 4.03C.
Logical OR (||)always returns true or false--this is incorrect behavior. Logical OR should return the value that was last evaluated. This is corrected in 4.03C.

Version 4.03A errata (may apply to earlier versions)

All 4.02 bugs described below have been fixed.
Using the jseOptDefaultLocalVars flag will disable the feature that automatically converts undefined variables to object when they are first used as object. For example, with jseOptDefaultLocalVars. In those cases use the var keyword or new Object() before using the variable as an object.
The jseCopyBuffer and jseCopyString functions will always convert start to start+length, and so the results will be invalid
The jseGetArrayLength and jseSetArrayLength do not validate data type that the variable is an object, string, or buffer type.
Some 16-bit compilers lose low-byte information when performing bitwise operations with 0x80000000L (highest-bit set). For example, the following comparison will fail on these systems: 0x80000000 | 0x1 == 0x80000001. This but will be fixed with release 4.03B.

Version 4.02 errata (may apply to earlier versions)

All 4.01 bugs described below have been fixed.
All objects now have the _defaultValue internal method.
Dynamic property names in now have an '_' as their first character; e.g. what was 'get' is now '_get' and so forth. This was done because the simpler names could be mistakenly used as variable names causing difficult to track bugs.
#define does not replace text strings that are part of a full dot-delimited function name. For example, the following function will not call me.goo()
Technically this is illegal ECMAscript/JavaScript. According to that standard this would have to be accomplished with something like this:
We "Extended" the rules by allowing the "function foo.goo() { }" statement because it is so useful. But our #define preprocessor (which itself is an extension of ecmascript) does not make this replacement. The workaround is to follow standard ECMAScript if object.functions are to be defined in-line.
With MSVC using 16-bit integers and 32-bit pointer, conversion from a primitive type to an object can fail (report invalid number of parameter to _constructor, construct incorrectly, or crash). This is fixed in version 4.02C and later.

Version 4.01 errata (may apply to earlier versions)

Variables that are read from without being defined are not flagged as an error
Variables that are assigned to without being declared in a function are created as local variables. ECMAScript says to create them as global variables. To ensure variables are globals, simply declare them outside of any function using the var keyword.
Only ECMA objects had the _defaultValue internal method