Integration SDK Errata (Earlier Versions)
Errata for pre-4.10c Versions

• 4.10b API - latest update: July 9, '99
• 4.10a API
• 4.03c API
• 4.03b API
• 4.03a API
• 4.02a API
• 4.01 Documentation
• 4.02 Documentation

  Version 4.10b API errata (may apply to earlier versions)

• Comparison between Buffers and Strings was not working correctly. This has already been fixed in 4.10c. Contact Nombas if you need the fix in older versions.
• Assigning a short buffer variable to a longer buffer variable will retain the longer variable's length. The fix in VARWRITE.C function varPutData() is to change the last parameter in the last call to varmemValidateIndex() from VString==vType to True.
• A literal non-string value in script source followed immediately by a literal string value can result in an unreleased variable. The fix in the CompileStringToken() function of CODEPRT2.C is to move the statement VAR_REMOVE_USER(PreviousVar,call); at about line 131 outside of the if block it is in.
• jseInterpret() may return True if the script compiles but there is a run-time error. It should return False in this case. The fix is to check the error flag on the Call structure before clearing it.
• Object created by new operator inherits, by default, from Function.prototype, but should instead inherit from Object.prototype. The fix is in callFunction() in SECODE.C, to change:
    && prop != call->Global->FunctionPrototype /* default */
  to
    && prop != call->Global->ObjectPrototype /* default */
• jseSetGlobalObject() does not ensure that the new global variable is a true readable variable (i.e. not a dynamic-get or -put waiting to happen). There is no fix for this "problem", because too much code relies on constancy of the global variable. For 4.10C we will be adding JSE_API_ASSERT statements in the jseSetGlobalObject() function in UTIL.C to warn of invalid variables being used as the global.
• Extra VAR_REMOVE_USER when freeing dynamic-write (i.e. ._put()) variables. Fixed in 4.10C. This is very unlikely to show up as a bug because the use of macros will hide any real loss of variables in this case. The fix is to remove the first call to VAR_REMOVE_USER() in the function varReallyRemoveUser() of VAR.C.
• Conversion of numeric-named object properties may be inconsistent in 16-bit environments. This has shown up in the .arguments property of a function. Fixed in 4.10C. The fix is to cast number as (JSE_POINTER_SINT)number in the EnterNumberIntoStringTable() macro of CALL.H.
• Library initialization using the JSE_VARSTRING() macro will crash if the interpreter is built without the JSE_COMPILER portion defined. Fixed in 4.10C. Contact Nombas if you need to code to workaround this problem.
• Functions registered with jseCallAtExit() that reference global variables will not flush the global variable cache on exit. This is fixed in 4.10C. The fix is in secodeEndFunction() in SECODE.C, to execute the global flushing even if no_clean flag is not set.
• Functions with more than one identically-named input parameter (e.g. function foo(ho,he,ha,ho)) will use the wrong parameter. This is fixed in 4.10C. The fix is about 15 lines into the localExecute() funcion in LOCLFUNC.C, reversing the for loop as follows:
    for( count=0;
         count<(int)this->InputParameterCount;
         count++ )
• Modulo operator truncates numbers that cannot be represented by a long integer. Fixed in 4.10C. The fix is in the Modulo case in do_twonumbers(), to use fmod() instead of C's % operator.
• Passing more than 127 parameters to a script method may result in a run-time error message about a negative number of parameters. This error did not appear in earlier releases. Fixed in 4.10C. The fix is to change the first line in libfuncExecute() of LIBRARY.C from sword8 VarCount = (sword8)callParameterCount(call); to uint VarCount = callParameterCount(call);
• C++ application link errors due to C-type headers. This is fixed in 4.10C. The fix is to use an extern "C" block around the prototypes in SEAPPSRV.H and SEOBJFUN.H.
• _put functions inherited through _prototype are not being called. This is fixed in 4.10C. The fix is to change varGetDirectMember() to varMemberGet() near the end of varPutValue() in VAR.C.
• When your jseMayIContinueFunc function returns false, not all variables in the currently-executing function are cleaned up. This is fixed in 4.10C. The fix is to replace callDelete() with secodeEndFunction(tmpcall) in the while() loop within the interpretTerm() function in INTERPRT.C.
• Parsing error in global code or main() script function causes crash. Fixed in 4.10C. The fix in CODEPRT2.C function functionparmsDelete() is to not call VAR_REMOVE_USER() if the function name is init_function_entry or main_entry.
• Potential comparison when compiling with JSE_INLINES=0 (usually only set for low-memory situations). Fixed in 4.10C. The fix in VARUTIL.C is add parentheses around the second half of the conditional macro for VarTypeConvertToPrimitive(); i.e., at about line 1055 change this pseudocode:
     ((VObject == VAR_TYPE(*var)) ? ExprA : ExprB, ExprC
  to
     ((VObject == VAR_TYPE(*var)) ? ExprA : (ExprB, ExprC)
• Warning:VAR_REMOVE_USER and VAR_THOROUGH_REMOVE_USER are macros containing an if statement and so are vulnerable to invalid else clauses. Although there are no such errors in the shipping code, the potential for adding errors is there if you're modifying the code in the SRCCORE directory. We've changed these in 4.10C to use a safe macros.
• String table can become corrupt if your hash-size entry is very small. This is fixed in 4.10C. The workaround is to keep the hash-size at the default. If you need a smaller hash size contact Nombas for the code fix.
• jsePutString(), jsePutStringLength(), and jsePutBuffer() may put invalid data in the modified variable if the data pointer comes from that variable itself and if putting this data causes the variable size to grow. This situation is rare. Fixed in 4.10C.
• Variable attributes are stored in varmem structure, so that two variables sharing a varmem also share the same attributes; attributes should be stored in the var structure. This is fixed in 4.10C. The fix is to move the attributes value from the varmem structure to the var structure in VAR.H--compile-time errors will then bring attention to the few lines that need to be modified.

  Version 4.10A API errata (may apply to earlier versions)

• Strings with embedded NULL characters or not ending in a NULL character are being incorrectly entered into the string table. This is only known to effect the tokenize/compile functions. This is fixed in 4.10B. The fix is to change the name-length assignment in the EnterIntoStringTable() function in CALL.C to assign to length and not to strlen_jsechar(). Related: correction of this problem allows GetDotNamedVar() to be optimized and no longer require an extra allocation.
• Characters with values greater than 127 may appear as negative values on ISDK applications that are not using unicode and that define char as as signed value. This is fixed in 4.10B. The fix is to typedef "jsechar" as "unsigned char" in JSETYPES.H
• jseCreateCodeTokenBuffer() is skipping local functions with dots in their names (e.g. function foo.prototype.getArea()). This is fixed in 4.10B. The workaround in 4.10A is to avoid using this syntax in scripts that will be tokenized.
• Incorrect precision, and truncated exponent, in converting numbers to string. This is fixed in 4.10B. The simplest workaround in 4.10A is to use "%.21g" as the format string for conversion in both SEOBJECT.C and VARUTIL.C, and also to remove the subsequent portion in SEOBJECT.C that removes terminating zeroes.
• Conversion to primitive data type will report an error if toString or valueOf (whichever is called first) not return a primitive data type. This is fixed in 4.10B. The fix is to modify the varDefaultValue() function in VARREAD.C to try both methods if the first does not return a primitive.

  Version 4.03C API errata (may apply to earlier versions)

• New macros (jseCompareLess() and jseCompareEquality()) have been added to give the API user exact control over comparisons.
• An extra null is incorrectly added to the end of buffers when converting them using convert_var_ToBuffer, which is called by jseCreateConvertedVariable(). This will alter the length of the buffer, and could introduce other problems. This will be fixed in 4.10. The fix is to the convert_var_ToBuffer() function in VARUTIL.C, as follows:
  
  line 530: change length+1 to length
  line 538: delete line
  line 539: change length+1 to length
  
• Special strings are incorrectly identified as numbers, causing errors whenever some types of names are entered into the string table. The string "-" would incorrectly be converted into the number 0, and strings with leading zeros, i.e. "00004" would be converted to the number 4. For example, after this:
  
  foo["-"] = 1;
  foo[0] = 2;
  foo["0000"] = 3;
  
  foo[0] would equal 3, and foo["-"] and foo["0000"] would be undefined. This will be fixied in 4.10. If you need the updated code for 4.03 contact http://support.nombas.com/.
• String representations of numeric indices may be overwritten if occurring simultaneously in multiple threads. For example, if two separate threads are each getting the name of a numeric member of an object (e.g., "14" in foo[14]), perhaps in a dynamic function callback or error message, they are both using the same static buffer for number-to-string conversion. This is fixed in 4.10. The fix is to use a per-Call->Global buffer in GetStringTableEntry() function of CALL.C.
• Buf in null-length string concatenation: Cancatenating two empty strings (e.g. "" + "") can result in a system crash, or at least a debug error, depending on your compiler. This is fixed in 4.10. The workaround is to change the HugeMalloc call in the ConcatenateStrings() function of VARUTIL.C to allocate an extra byte, for example:
  
  ConcatMem = (jsechar _HUGE_ *)HugeMalloc(len1+len2+1);

  Version 4.03B API errata (may apply to earlier versions)

• enum conversion errors in the source. For those who have licensed the SRCCORE files and are recompiling for different platforms, beware of two known conversion problems involving enums compared with negative constants. The first problem is in parsing source-file keywords, such as true, null, and false. The second problem is if debugging is turned on and pre-compiled tokens are being played back, you may wrongly receive a report that the compiled code is invalid. These conversion problems will be fixed and tested before the next release. Workarounds: if you are compiling the core files into a separate library, then use the option available with most compilers to treat enums as signed; or contact http://support.nombas.com/ request more workaround information. This problem will be correct with release 4.10.
• jseFindNames() function is missing. This function has been mysteriously dropped from the current API, and it's loss was caught late because it was not tested in our test suites. This API function will be restored in version 4.10. Source-code licensees will see that this is a simple wrapper around the FindNames() function in varutil.c.
• Our memory allocation wrappers, when built with debugging tools enabled, is not testing for size-zero memory allocation and reallocations. This will be fixed in 4.03C. The only known location where this could produce an error is when compiling/decompiling scripts containing zero-length strings.
• Depending on your compiler, processor, and compile-time options, executing scripts can generate floating-point exceptions (such as overflow or underflow) that are not caught within the ISDK code. We are currently investigating all of the issues involving this problem and portable solutions, and will implement the best solutions in version 4.10. Contact http://support.nombas.com/ for more information about this issue if it is a problem on your system..
• String comparisons results may be incorrect. For example ("8"<="9") would correctly be true, but ("7"<="9") would be incorrectly be false. This is corrected in 4.03C. To fix this problem in the do_op_compare() function of COMPARE.C, change the comparison (result == -1) to (result < 0) and change (result == 1) to (result > 0).

  Version 4.03A API errata (may apply to earlier versions)

• jseDestroyVariable() will report that the variable is invalid if the variable was created with one of the jse...Member...Ex() calls using the jseCreateVar flag. Memory associated with this variable reference will not be freed. This will be corrected in release 4.03B. If you have a source-code license, remove the large section checking that varGetTheMember(variable)!=NULL
• jseLibSetExitFlag() will cause the interpreter to act as if an error were encountered, and will cause the jseInterpret() function to return False. This will be corrected in release 4.03B. The workaround is to ignore the error, and if the exit variable information is needed then store that information in some other location.
• jseActivationObject() will always return the global object if called from within a wrapper function, instead of returning NULL to indicate that it is in a local function. This will be corrected in 4.03B. The workaround is to repeatedly call jsePreviousContext() and then jseActivationObject() until the value return is not the same as jseGlobalObject().
• If two threads call jseInitializeEngine() and then one thread calls jseTerminateEngine() and then the other thread calls jseTerminateEngine(), then jseApiOK and jseGetLastApiError() will both report an error on the second call to jseTerminateEngine(). This will be corrected in 4.03B. The workaround is to ignore this error message.
• jseInterpret() may have playback errors interpreting scripts created with jseCreateCodeTokenBuffer() if any local functions in the script use input parameters. This will be corrected in 4.03B.
• #ifdef and #ifndef processing rely on the defined() function having been added as a global function. This will be corrected in 4.03B so that no function need to be defined before using #ifdef or #ifndef. The simplest workaround is just to add the defined() wrapper function, as found in /SECLIB/SELIB.C. If adding that function is impractical, then alter the source in SRCCORE/SOURCE.C for the sourceEvaluateConditionalCompilation() function as follows
    /* create wrapper around statement to interpret */
    jse_sprintf_2( command_buf, "%s %s",
                   AutomaticDefineFunc
                 ? "\"undefined\" != typeof"
                 : "", SourceStatement );
• Pre-compile code (i.e. the code create by jseCreateCodeTokenBuffer() and played back via jseInterpret()) has some small differences between targets and compile options. For instance, code compiled from a system supporting the #link option would not play back from a system that did not support #link, but there were other problems as well. This will be corrected with version 4.03B.
• The conversion bits in jseFuncVarNeed() (i.e. those bits defined by the macro JSE_VN_CONVERT()) are ignored in 16-bit Borland and Microsoft builds. This will be corrected in 4.03B.

  4.02a API errata (may apply to earlier versions)

• Problem: in string.split(separator) method, if the length of the separator is greater than or equal to string, it returns wrong value. Correction: fixed in file srclib\ecma\seobject.c

• jseGetFunction will crash if the function does not exist.  As a work around call jseGetMember and jseIsFunction as shown here:

    jseVariable m;
    
    m = jseGetMember(jsecontext, NULL, "PrintFloat");
    if(m)
    {
       jsebool b;
    
       b = jseIsFunction(jsecontext,m);
       if(b)
       {
          /* it's safe to call the function now */
          jseCallFunction(jsecontext, m, stack, NULL, NULL)
       }
    }
    

• "delete z (where z is undefined variable) bug". Workaround: Verify that the object exists (check its type) before calling delete.
• The jseInterpret() API call now returns a variable rather than a numeric return code. Similarly, the eval() function now correctly returns whatever value was 'return'ed or the value of the last executed expression if none.

  Version 4.02 documentation errors (may apply to earlier versions)

• jseCallFunction () *returnVar will never be NULL. The manual (and previous versions of SE:ISDK) state that *returnVar may be set to NULL to indicate that the function did not return anything. This is no longer true with ECMA-262. All functions now return a value. If they do not explicitly return a value then they implicitly return an jseTypeUndefined variable. Starting with version 4.02, if you want to check that a function did not return a variable then check jseTypeUndefined!=*retVar. (BTW, this case is indisitinguishable from explicitly returning an undefined variable.)

  Version 4.01 Documention changes (may apply to earlier versions)

• jseCompare (page 40) incorrect syntax for the third parameter, the correct syntax is: jseCompare(jseVariable variable1, jseVariable variable2, slong * compareResult);
• jseEvaluateBoolean (page 53) the syntax included sn extra comma.  the correct sytax is: jseEvaluateBoolean(jseContext jsecontext,jseVariable variable);
• jseGetIndexMember (page 61) The comment states "If the member does not exist it will be created with an undefined value."  This is incorrect.  The the return value is stated,it will return NULL if the mamber does not exist.   The last paramter is incorrect.  The correct syntax is: jseGetIndexMember(jseContext jsecontext,jseVariable objectVariable,slong index);
• jseInitializeExternalLink (page 68) The syntax was changed to include a token buffer parameter.  The new syntax is: jseInitializeExternalLink(void _FAR_ *LinkData,struct jseExternalLinkParameters *LinkParms, const char _FAR_ * globalVarName,const char _FAR_ * AccessKey);
• jseInterpret (page 71) jseInterpret now return a jseVariableas the script return code.  the new syntax is: jseInterpret(jseContext jsecontext,JSE_CPP_CONST char _FAR_ * SourceFile,JSE_CPP_CONST char _FAR_ * SourceText,JSE_CPP_CONST void _FAR_ * PreTokenizedSource,JSE_CPP_CONST jseSourceFilters _FAR_ SrcFilters, jseNewContextSettings NewContextSettings, int howToInterpret,jseContext localVariableContext,jseVariable _FAR_ *returnVar);
• jseInterpret (page 72) The howToInterpret flags are incorrectly stated to begin with 'CMM_',  The correct prefix is 'JSE_'.
• jseLibSetExitFlag (page 75) The call now takes a jseVariable as the exitCode paramter.  the new syntax is: jseLibSetExitFlag(jseContext jsecontext,jseVariable variable);
• jseLoadTokenBuffer (page 76).  this call longer exists.  In place if it you should use the new parameter to jseInterpret().
• jseQuitFlagged (page 85) The return macros incorrectly state the prefix as 'CMM_' the correct prefix is 'JSE_'.
• jseSetArraySpan (page 89) is incorrectly named.  The correct name is jseSetArrayLength.