Nombas Homepage







Nombas > SE:ISDK DevSpace > Errata > Integration SDK 4.20x Errata


Integration SDK 4.20x Errata
Fixes Affecting Users of the ScriptEase ISDKs

   Documentation errata:

API Errata, version 4.20d (may apply to earlier versions)
  New, March 20, 2003

API Errata, version 4.20c (may apply to earlier versions)
  New, March 20, 2000

  As of February 25, 2000 : for 4.20c

  As of February 4, 2000 : for 4.20b (may apply to earlier versions)

Documentation Errata

  version 4.20 :


The Details

for 4.20d --

  • COMOBJ leaks resources
    (for ISDK/C 4.20d)

Bug: COMOBJ can leaks resources when working with type libraries and pass-by-ref COM objects. Over time total memory use will grow.

Fix: Replace srclib/comobj/* code with files found at

  • jsePush(...True...) not destroying variable
    (for ISDK/C 4.20d)

    Bug: jsePush() is supposed to destroy a variable reference when the stack is destroyed (with jseDestroyStack) when the last parameter (DeleteVariableWhenFinished) is True. But this is only working in debug builds. When NDEBUG is defined the variable is not deleted with the stack but remains until the context is destroyed.

    Fix: In srccore/util.c, replace the function jsePush() with the one found at

  • JSE_FIXEDSTACK is recommended
    (for ISDK/C 4.20d)

    Problem: JSE_FIXEDSTACK=0 option is buggy and doesn't provide much savings in memory or performance.

    Fix: We recommend enabling JSE_FIXEDSTACK in all cases. It is already on by default unless JSE_MIN_MEMORY is enabled. To ensable in all cases simply comment out this in srccore/srccore.h

    # define JSE_FIXEDSTACK 0

    so that it is:

    /* # define JSE_FIXEDSTACK 0 */

    If you want to save the additional memory for JSE_MIN_MEMORY situations you may choose to reduce the define value for JSE_FIXEDSTACK_DEPTH.

locating error variable names takes long if global is aliased
(for ISDK/C 4.20d)

Error: If a name is being generated to describe a variable during creation of an error message, and if properties of some objects are assigned to the global variable (e.g. a._prototype=global) then generating that variable name can take a long long long time, so long that the process may seem hung.

Fix: In VARUTIL.C function IsThisTheVariable() there are four four "SEEN" macros (VAR_MARK_SEEN, VAR_MARK_NOT_SEEN, & VAR_WAS_SEEN), these should all become VAROBJ macros instead. I.E.

   VAR_WAS_SEEN(me)      ->  VAROBJ_WAS_SEEN(VAR_GET_VAR_OBJ(call,me))

Error with auto-decrement (--) on dynamic _put
(for ISDK/C 4.20d)

Bug: If foo is a dynamic object object with a _put operator, then a statement such as "foo.a--" may act just like "foo.a++".

Fix: In SECODE.C, function secodeInterpret() at about line 1345, change this line
to this:

Comma error converting functions to strings
(for ISDK/C 4.20d)

Problem: When converting script functions to strings in SE:ISDK/C 4.20, there may be a crash or an assert failure on some functions containing commas. For example, the following script will crash or suffer an assert failure:
      function foo()
         var a, b; // the comma on this line will cause a crash
      var foo_str = "" + foo;

Fix: In FUNCTION.C, function functionTextAsVariable() at about line 324 is this statement:
     case getParamValue:
Change that line to this:
      case getParamValue: case popEval:

Reallocation error with JSE_MEM_DEBUG on multi-threaded systems
(for ISDK/C 4.20d)

Problem: When compiling in debug mode (JSE_MEM_DEBUG=1) the re-allocation routines are not thread-safe.

Workaround: In JSEMEM.C function jseUtilReMalloc() move the ExclusiveMallocThreadStop() after the memcpy() line.

Precision lost in floating-point values
(for ISDK/C 4.20d)

Problem: In SE:ISDK/C 4.20d and earlier releases data precision is lost in converting floating-point values to string. For instance, "" + 1.12345678901234567 may result in "1.12345678901"

Workaround: You can turn off the rounding algorithm by compiling with JSE_NUMTOSTRING_ROUNDING=0, or replace the code for SRCMISC\UTILSTR.C function EcmaNumberToString() with the function found in

Error setting variable attributes on a dynamic-write object
(for ISDK/C 4.20d)

Problem: In SE:ISDK/C 4.20d assertions are triggered when setting the attributes on a variable which is a _put waiting to happen. This can be a result of jseSetAttributes() or any function that calls jseSetAttributes, such as jseMemberWrapperFunction().

Fix: In JSELIB.C function jseSetAttributes() add a Var name tmp and change

      var = GET_READABLE_TO_STACK(jsecontext,validateVariable(variable));


      tmp = validateVariable(variable);
      /* cannot set attributes on a dynamic put waiting to happen */
      if( tmp->type==VDynamicPut || tmp->type==VFakePut )
      var = GET_READABLE_TO_STACK(jsecontext,tmp);

and in VAR.C function getWriteableTo() change

      assert( this->type!=VDynamicPut && this->type!=VFakePut );


      if( this->type==VDynamicPut || this->type==VFakePut )
         if( target!=this )
         return target;

and in function varAssignEx() change

      if( var->type==VDynamicPut || var->type==VFakePut )
      if( var->type==VLValue )
         var = var->data.lvalue_val;


      if( var->type==VLValue )
         var = var->data.lvalue_val;
      orig = var;
      if( var->type==VDynamicPut || var->type==VFakePut )


for 4.20c --

Rounding error on date calculations
(for ISDK/C 4.20c)

Problem: Rounding errors can cause hours to be rounded-down on some years. For example, the result of new Date(1997,1,9,5,0); may incorrectly show the time "04:00:00" where it will be correct had most other years been chosen.

Workaround: in SEDATE.C function HourFromTime() provide an extra "hint" for rounding by changing floor(t/msPerHour) to floor((t+0.01)/msPerHour)

constructor crash if constructor is not valid function
(for ISDK/C 4.20c)

Error: If a constructor function is not really a function, but is some other data type, a crash is likely.

Fix: In function varCallConstructor() of VARUTIL.C, replace this code at the top:

func = varGetConstructor(call,this);

with this:

if( this->type==VLValue ) this = this->data.lvalue_val; 
if ( VObject != this->type
|| NULL == (func = varGetConstructor(call,this)) )

"arguments" object incorrectly constructed
(for ISDK/C 4.20c)

Error: The "arguments" object is incorrectly constructed when used in a script function.

Fix: In CALL.C, function callLocalFunction(), replace the existing loop with:

    for( x=0;x<num_args;x++ )
       VarName name = NumericStringTableEntry(x);
    Var cgVar = callGetVar(call,x);
    if( cgVar->type==VLValue )
    /* pass by reference parameter */

    /* regular parameter, make copy of the data */
    Var tmp =
    /* and have stack var point to that data */
    } }

Garbage Collector won't release inherited destructors
(for ISDK/C 4.20c)

Bug: Inherited destructors (SomeObj.prototype._delete) are not being called after the Garbage Collection pass.

Fix: There are a lot of related fixes for this problem. Update to release 4.20D


Overlapping memory blocks with varChopFromLeft()
(for ISDK/C 4.20c)

Problem: overlapping memory blocks with varChopFromLeft()

Fix: In srccore/garbage.c:837 function varChopFromLeft(): HugeMemCpy should be changed to HugeMemMove since the blocks of memory may overlap.

Unallocated memory read with extensionLinkOnto()
(for ISDK/C 4.20c)

Problem: The existing StrCpyMallocLen in extensionLinkOnto() may have read unallocated memory.

Fix: In srccore/extlib.c:374 function extensionLinkOnto(): Change the StrCpyMallocLen to the following:

    /* allocate memory for file name plus a little just-in-case. 

     * Can use strcpy even in MBCS because it is NULL-terminated. 


    FullFileName = jseMustMalloc(jsecharptrdatum, 




Siblings of objects trying to access bad memory
(for ISDK/C 4.20c)

Problem: With varSibling(), siblings of objects may try to access bad memory.

Fix: In srccore/var.c:896 function varSibling():
(The first few lines and the the last few lines remain the same, they are provided so you can figure out where to put the stuff that has changed in the middle.)


     ASSERT_VALID_VAR( relvar ); 


     if( VAR_ARRAY_POINTER(relvar) ) 


        if( relvar->>constant!=0 ) 



        dest->data.string_val.loffset += offset; 






     /* We only actually validate the index when we go to use 

        it,that is done in varAssign()/varGetNumber().      */ 

Unintentionally freed items
(for ISDK/C 4.20c)

Problem: Undefined memory and possibly having the garbage collector's 'already marked' bit on leading to items being thought to be free when they were in fact in use (thus, they got freed.)

In call.c:183 function callLocalFunction(): Old lines 183 and 184 used VAR_INIT_UNDEFINED, change that to:



call.c:549 function callWrapperFunction(): Similar change, so the line now reads:


util.c:717 function callInterpret(): Yet again the same king of change:


var.h:815 Add a definition for VAR_MAKE_VALID:

    #define VAR_MAKE_VALID(v) (VAR_INIT_UNDEFINED(v),(v)->flags = 0) 

A struct seVar and garbage collection
(for ISDK/C 4.20c)

Problem: A struct seVar was allocated as a local variable, which is bad because the garbage collector has no way to know about it, so anything it points to may get collected.

Fix: In call.c:1470 function callPrintError(), change:

    struct Var loc; 


    struct Var *loc = stackPush(this); 

Add right after the local variable declarations:


Get rid of the previous initialization of 'loc'. All references in the function to '&loc' should be changed to just plain 'loc'.

Finally, as the last line of the function, add the following:


Invalid return from jseGetCurrentThisVariable()
(for ISDK/C 4.20c)

Problem: value returned by jseGetCurrentThisVariable() is invalid if there is not a variable assigned to "this"

Fix: If there is no explicit "this" variable, the current global variable will be assigned as the “this” variable.
This can be accomplished with the following code changes:

UTIL.C, function callInterpret(), at about line 724 change

          assert( call->old_init==NULL ); 

          return call; 


          assert( call->old_init==NULL ); 

          call->This = call->GlobalVariable; 

          return call; 

UTIL.C, function callInitial(), right before the last line of the function (line 884), add:

          call->This = call->GlobalVariable; 

Wrong variables compared with Strict equality & inequality
(for ISDK/C 4.20c)

Problem: Strict equality (= = =) and inequality (!= =) may compare wrong variables.

Fix: at the top of function varCompareStrictEquality() in VARUTIL.C, change this code:

    VarType vtype = VAR_TYPE(vx); 

to this:

    VarType vtype; 

    if( vx->type==VLValue ) vx = vx->data.lvalue_val; 

    if( vy->type==VLValue ) vy = vy->data.lvalue_val; 

    vtype = VAR_TYPE(vx); 

Calling jseFindVariable() from wrapper with dynamic _hasProperty
(for ISDK/C 4.20c)

Problem: calling jseFindVariable() from a wrapper function when entries in the enclosing script's scope chain have a dynamic '_hasProperty' function will be using the wrong call (one other than the latest) to call those dynamic functions.


(a) in call.c, line 603 (function FindVariableByName) 

     change the 3 instances of varHasProperty(). In 

     each case, the first parameter is 'this'. Change 

     that to 'callCurrent(this)' 

(b) in util.c, line 1159. Change the definition of 

     callCurrent() to not be static. 

(c) in call.h, line 748, add the declaration for 

     callCurrent(), as 


     struct Call * callCurrent(struct Call *this); 

_put function not called with jseEcmaArray attribute
(for ISDK/C 4.20c)

Problem: _put function is not called on variables with the jseEcmaArray variable attribute.

Fix: in VARUTIL.C function varPutValue(), varAssign() is always called directly if the IS_ARRAY flag is set. This block needs to check if there is a _put method for this object and fall-through to the call-dynamic-method block if there is a _put.

PrintErrorFunction not immediately called
(for ISDK/C 4.20c)

Problem: sometimes your PrintErrorFunction will not be called immediately, even when exceptions are not being trapped

Fix: In util.c, callInitialGlobal, right after the memset() 6 lines in the function, add,

   this->mustPrintError = True;

Incorrect filename/line number reporting
(for ISDK/C 4.20c)

Problem: Error messages, jseLocateSource, and the debugger may return incorrect filenames and line numbers when reporting on global source-file lines of files that have been #include'd.

Fix: In UTIL.C, function secodeSourceLocation(), remove the "break;" statement following this line:

   *name = GetStringTableEntry(call,...);

Only first error printed with multiple calls
(for ISDK/C 4.20c)

Problem: Only the first error is printed if errors occur during multiple calls to execute a function.

Fix: In JSELIB.C function jseCallFunctionEx, add this as just before the last statement ("return retbool;");

    jsecontext->errorPrinted = False;

no line number on error when interpreting text from source
(for ISDK/C 4.20c)

Problem: If an error occurs while interpreting text for source (i.e., not from a file), the line number where the error occurred is not printed in the error message.

Fix: In CALL.C function ErrorVPrintf() replace this line (at about line 1273)

      /* If possible find line number information and add that */

    if (secodeSourceLocation(this,&SourceFileName,

        &SourceLineNumber) &&

        SourceFileName!=NULL )

with this

       /* If possible find line number information and add that */

    if (secodeSourceLocation(this,&SourceFileName,

        &SourceLineNumber) )

and a few lines later add:

    SourceFileName = StrCpyMalloc( SourceFileName ? 


       : textcoreGet(this,textcoreInlineSourceCodePhonyFilename);

after the call to jse_sprintf add:

   jseMustFree((void *)SourceFileName);

for 4.20b --

Syntax Error 1521, prototype chains
(for ISDK/C 4.20b)

Error: Syntax Error "1521: prototype chains cannot be circular" if not using the standard ECMA objects found in srclib\ecma\seobject.c

Fix: This can be corrected by adding this line to the FunctionProtoList[] in UTIL.C before the prototype._class entry.

   JSE_VARSTRING( UNISTR("prototype._prototype"),


                         jseDontEnum ),

Literal strings lost with pre-compiled code
(SE:ISDK/C 4.20c)

Problem: While reading in pre-compiled (i.e., jseCreateCodeTokenBuffer) code, literal strings may be lost or overwritten.

Fix: Fix: in VARUTIL.C, function TokenReadVar(), replace this code,

   VarRead var = varCreate(call); 

with this code:


   VarRead var = varCreate(call); 



and remove the callAddTempVar(call,var) line from the end of this function.

Problem with error reporting
(for ISDK/C 4.20b)

Problem: undefined members of global variables may not have names printed in error messages.

Example: Variable "" is not a function type

Fix: In VARUTIL.C function FindNames (approx. line 206), change:

   for( i=0;;i++ )


   for( i=0;!FoundName;i++ )

Errors in some MBCS String functions

Problem: There are errors in some of the String functions for MBCS versions.

Fix: These problems are fixed in 4.20c. Contact Nombas if you're working with the MBCS builds and need these fixes right away.

Performance Issue with 4.20b

Problem: Some string functions, particularly adding strings and converting a string datum to a string Object, are performing more slowly with the 4.20 release, usually just a few percent slower.

Fix: These problems will be fixed in 4.20c. Contact Nombas if you are having performance degradation problems with strings in 4.20b.

memory problems with convert_var_to_string (ISDK/C 4.20b)

Problem: memory may become corrupt when converting a string object to a string datum.

Fix: Replace the function convert_var_to_string() in file,


with the code in -

Clib.scanf and variables in GUI versions (ISDK/C 4.20b)

Problem: Clib.scanf() will not set variables in GUI versions.

Fix: In SESTDIO.C function FScanFFamily(), the first three instances of -


should instead be -



Problem: jseConstructObject() may not call correct constructor for objects with no explicit _construct property.

Fix: Replace the function jseConstructObject() in file:


with the code in:

"-0" is parsing as +0 in some systems (ISDK/C 4.20b)

Problem: in some systems "-0" is parsing as +0 and not as -0 .

Test: With the test object included ("#link " or "#include "), this statement will fail if your compiler has this problem:

   Test.assert( Test.isNegZero( Number("-0") ) );

Workaround: in UTIL.C function convertStringToNumber(), after the block starting with:

   if ( lenParsed != lenStr )

add this code:

   else if ( '-'==JSECHARPTR_GETC(str)  &&  jseIsPosZero(val) )

      val = jseNegZero;

Blob.get() with negative integers() (ISDK/C 4.20b)

Problem: Blob.get() may translate sign incorrectly for negative integers() .

Depending on your compiler, you may falsely get a negative statement out of a script such as this:


    return Blob.get(buf,0,UWORD32);

or the following may falsely return -1


    return Blob.get(buf,0,SWORD32);

Fix: in seblob.c, function blobGetByValue(), at about line 796, change:

     assert(blobUWORD16 == type ||

            blobUWORD24 == type ||

            blobUWORD32 == type );



     assert(blobUWORD16 == type ||

            blobUWORD24 == type ||

            blobUWORD32 == type );


and a few lines later, change:



   if ( !((-type) & 1) )




Clib.getch(), Clib.getche() receive only from real keyboard (ISDK/C 4.20b)

Problem: If keyboard is redirected via Clib.freopen(), Clib.getch() and Clib.getche() are retrieved from the file instead of from the real keyboard. These functions should always receive from the real keyboard.

Fix: in sestdio.c function _sestdio_getch_() delete this section of code:

   && fileSystemIsConsoleFP(jsecontext,stdin)

GenericGetDataPtr() (ISDK/C 4.20b)

Problem: memory may become corrupt when preserving data retrieve from a string or buffer datum via dynamic _get .

Fix: Replace the function GenericGetDataPtr() in file:


with the code in:

Subtracting strings, non-finite numbers (ISDK/C 4.20b)

Problem: with some compilers, subtracting strings does not give correct answers for non-finite numbers (e.g., foo = "Infinity" - "NaN" )

Fix: In OPERATOR.C function do_add_or_subtract() at about line 522 change this code:

    /* subtraction will treat both sides as numbers */

    lnum = GetNumberForOperator(call,rlvar);

    rnum = GetNumberForOperator(call,rrvar);


    newVar = STACK_TOP(call);

    VAR_INIT_NUMBER(newVar,lnum - rnum);

To this:

    /* subtraction will treat both sides as numbers */

    lnum = GetNumberForOperator(call,rlvar);

    rnum = GetNumberForOperator(call,rrvar);

    goto QuickAddTwoNumbers;

Error with #link for some Unix systems

Problem: #link library loading problem with Solaris and Irix.

- for Solaris: srccore/extlib.c line 582, add right before the case for __JSE_UNUX__:

   #elif defined(__sun__)

    temphExtensionLib = dlopen(FullLibraryPath,


- for Irix:

all extlib makefiles changed the definition of



   EXT_LINK_FLAGS  = -shared -Xlinker -B -Xlinker symbolic

(Unix) Infinity and -Infinity parsing error

Problem: "Infinity" and "-Infinity" not parsed correctly on Solaris and possibly other Unix systems

Fix: In file UTIL.C at about line 1462, just before this line:

   val = ( 0 == strnicmp_jsechar(str,UNISTR("0x"),2) )

insert this code:

  #  ifdef __JSE_UNIX__

     assert(sizeof_jsechar('-') == sizeof(jsecharptrdatum));

     if(isalpha_jsechar(JSECHARPTR_GETC(str)) ||

       (*str=='-' && isalpha_jsechar(JSECHARPTR_GETC(str+1)))

       parseEnd = str;


  #  endif

++ not working with Nan for some systems (ISDK/C 4.20b)

Problem: ++ , on certain systems (IRIX), won't work with NaN correctly.

Fix: In secode.c, line 1355, insert this test:

   if( jseIsFinite(lhs->data.lvalue_val->data.num_val) )

right before the existing:

   if( t==opIncrement )



Similarly, in operator.c, line 705, insert:

   if( jseIsFinite(var->data.num_val) )

right before:

   var->data.num_val += delta;

and change the else block beginning at 737 to:



      double val = GetNumberForOperator(call,var);

      /* It is possible that the conversion to number failed,

       * in which case we don't want to overwrite the old

       * value, since we want to cease execution immediately.


      if( !CALL_QUIT(call)

         if( jseIsFinite(val) )









in srclib/ecma/ecmamisc.c, line 164, add:

   if( jseIsNaN(result) )






(The following first published August, 1999, or earlier.)

Deref variable not making space for new element

Problem: deref variable (i.e., a[1] in cfunction where a is string) was not making space for the new element being assigned. So a[0] = 1 doesn't grow to include a 0th element if it did not already.

Fix: in VARWRITE.C function varPutNumber(), after:

  if( varIsDeref(this) )

add this line:


FindNames with protected-memory systems

Problem: the FindNames function can crash protected-memory systems.

Fix: The simplest fix is to add this statement at the top of -

GetStringTableEntry() in CALL.C:

  if ( NULL == entry ) return NULL;

JseCallFunction()and MayIContinue

Problem: if calling jseCallFunction() and MayIContinue returns
false, then contexts may not be cleaned up.

Fix: In function.c/functionFullCall(), a short loop must be
added to end all sub-functions when MayIContinue() returns false.
Contact Nombas for this code if you need to add it to 4.10C.

Remote debugger hanging under Windows

Problem: Debugging session hangs when using remote debugger on
the Windows platform.

Fix: in PROXY.C, replace the functions DoWaitForReadLoop,
WaitUntilReadyToRecv, and WaitUntilReadyToSend with the

    static void NEAR_CALL
    DoWaitForReadLoop(struct tcpipInfo *ti)
    #if defined(__JSE_WIN16__) || defined(__JSE_WIN32__)
      MSG msg;

      while( !ti->GotWmSocketReadReady &&
        !ti->GotWmSocketCloseReady )
    # if defined(__JSE_WIN16__) || defined(__JSE_WIN32__)
        if( !GetMessage(&msg,0,0,0) ) return;
    # elif defined(USE_MAC_WINSOCK)
    # endif

    static void NEAR_CALL
    WaitUntilReadyToRecv(struct debugMe *debugme,SOCKET socket)
      struct tcpipInfo *ti =
        (struct tcpipInfo*)jseDbgInfo(debugme);

      unsigned long non_blocking = 0;


      ti->GotWmSocketReadReady = False;
      ti->GotWmSocketCloseReady = False;


    static void NEAR_CALL
    WaitUntilReadyToSend(struct debugMe *debugme,SOCKET
      struct tcpipInfo *ti = (struct tcpipInfo*)jseDbgInfo(debugme);

      unsigned long non_blocking = 0;

      ti->GotWmSocketWriteReady = True;
      ti->GotWmSocketCloseReady = False;


The function DoWaitForWriteLoop() may be commented out or
removed from the code altogether.


Problem: SECODE_STACK_PUSH() assumes compiler errors:

In a few cases, the use of the SECODE_STACK_PUSH macro makes
invalid assumptions about the C compiler. If your compiler has
this problem, then the engine will crash during initialization.

Fix: In function.c at about line 167, this code:


should become this code:

    VarRead *ret;
    ret = functionFinishCall(this,CallerCall->pChildCall,
        InputVariableCount, ThisVar)

In secode.c line 2100 this code:


should be:

    VarRead *tmp2;
    tmp2 = do_op_delete(call,tmp);

and a few lines below that this code:


should be:

    VarRead *tmp2;
    tmp2 = do_op_typeof(call,tmp);

ToolkitAppPrintError - No-unicode

Problem: Our default ToolkitAppPrintError function does not
handle Unicode.

Fix: The single statement in PRINTERR.C should become:

    fprintf_jsechar(stderr,UNISTR("Error %s\n"),

Alert about defineXXX() Functions

Alert: It is possible that the defineXXX() functions, as prototyped in DEFINE.H, will read from memory not allocated by the application. This has not been found to produce an error in any system.

Fix: in DEFINE.C function defineAddLen() the line containing "memcmp" should be changed to:

if ( 0 == strncmp_jsechar(FindString,(*plink)->Find,FindStringLen)

Fix For Memory Access While Deleting Call Structure

Problem: Invalid memory access while deleting a call structure.

Fix: Remove the following lines from the end of the callDelete() function in CALL.C

/* Don't restore a valid quit reason if
* calling a destructor failed -
* that's still a failure
if( !callQuitWanted(this) )

eval() function and JSE_MULTIPLE_GLOBAL

The eval() function may not recognize the correct variables when using the JSE_MULTIPLE_GLOBAL option and your code is use jseGetGlobalObject() to modify the global variable. The problem is that eval() is modifying the global to the original value, and not the value of its own context.

In srclib/ecma/ecmamisc.c, the function Ecma_eval. Right before the 'if ( !jseInterpret(...' line, the following should be added:

# endif

Implicitparents bug fix

(Note: this bug is probably important to only a few users, because very few probably use implicitparents or implicitthis on assigned methods of an object.)

Variable attributes may not be retained by methods assigned as members of an object. This is most likely a problem if you use the jseImplicitThis or jseImplicitParents attributes. SCOPE2.JSE in the test suite demonstrates this error.

Fix: Contact us at --
Tech Support

HTML-style comments (<!--) are not recognized by the core interpreter. This type of comment can be added by assigning JSE_HTML_COMMENT_STYLE=1 in your compiler environment, and by adding the following code after the IS_WHITESPACE statement in the CompileFromText() function of CODE.C:
  #if defined(JSE_HTML_COMMENT_STYLE) \
    if( src[0]=='<' && src[1]=='!'
     && src[2]=='-' && src[3]=='-' )
      goto EndOfSourceLine;

Documentation errata

4.20 documentation -- (Jan. 5, 2000)

  The following corrections are all for functions documented in the API Chapter.


- jseDestroyVariable unnecessary

Problem: In the API chapter, the Comments state that jseMemberWrapperFunction creates a function variable which must eventually be destroyed with jseDestroyVariable().

Correction: jseMemberWrapperFunction creates an internally-temporary variable which you should not destroy with jseDestroyVariable. The current edition of the documentation shows this correctly.

- returns a jseContext.

jseInterpInit() returns a jseContext, not jseBool as was shown. The current edition of the documentation shows this correctly.

for jseInterpTerm() - 2nd parameter

jseInterpTerm() takes a 2nd parameter, 'jsebool traperrors'.
If it is true, then jseInterpTerm() will return an error object if there is an error.
If it is false, it will print an error message and return false on errors.


Home | Scripting | Products | Purchase | Download | Support | Company

Copyright ©2001, Nombas, Inc. All Rights Reserved.
Questions? Visit