SDK Errata (Earlier Versions)
Errata for pre-4.10c Versions
4.10b API errata (may apply to earlier versions)
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.
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.
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 */
&& prop != call->Global->ObjectPrototype /* default */
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
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);
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.
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
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
((VObject == VAR_TYPE(*var)) ? ExprA : (ExprB, ExprC)
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
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.
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.
4.10A API errata (may apply to earlier versions)
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
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.
4.03C API errata (may apply to earlier versions)
macros (jseCompareLess() and jseCompareEquality())
have been added to give the API user exact control
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:
530: change length+1 to length
line 538: delete line
line 539: change length+1 to length
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:
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/.
foo = 2;
foo["0000"] = 3;
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), 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
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);
4.03B API errata (may apply to earlier versions)
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.
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
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
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).
4.03A API errata (may apply to earlier versions)
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
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.
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.
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
"", SourceStatement );
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.
API errata (may apply to earlier versions)
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
will crash if the function does not exist. As
a work around call jseGetMember and jseIsFunction
as shown here:
m = jseGetMember(jsecontext, NULL,
b = jseIsFunction(jsecontext,m);
it's safe to call the function now */
m, stack, NULL, NULL)
z (where z is undefined variable) bug". Workaround:
Verify that the object exists (check its type) before
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.
4.02 documentation errors (may apply to earlier versions)
() *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
4.01 Documention changes (may apply to earlier versions)
(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
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:
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_
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_ *
_FAR_ SrcFilters, jseNewContextSettings NewContextSettings,
int howToInterpret,jseContext localVariableContext,jseVariable
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:
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.