|
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 ftp://ftp.nombas.com/pub/isdkeval/se420/comobj_2003_03_20.zip
- 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 ftp://ftp.nombas.com/pub/isdkeval/se420/jsepush.c
- 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_MARK_SEEN(me) -> VAROBJ_MARK_SEEN(VAR_GET_VAR_OBJ(call,me))
VAR_MARK_NOT_SEEN(me) -> VAROBJ_MARK_NOT_SEEN(VAR_GET_VAR_OBJ(call,me))
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
do_op_crement(call,1);
to this:
do_op_crement(call,,(t==opIncrement)?1:-1);
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 ftp://ftp.nombas.com/pub/isdkeval/se420/bugfix.txt
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));
to
tmp = validateVariable(variable);
/* cannot
set attributes on a dynamic put waiting to happen
*/
if( tmp->type==VDynamicPut
|| tmp->type==VFakePut )
return;
var = GET_READABLE_TO_STACK(jsecontext,tmp);
and in VAR.C function getWriteableTo() change
assert( this->type!=VDynamicPut
&& this->type!=VFakePut );
to
if( this->type==VDynamicPut
|| this->type==VFakePut )
{
if(
target!=this )
VAR_COPY(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;
to
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)) )
{
varInitBlankObject(call,new_var);
callError(call,textcoreNOT_FUNCTION_VARIABLE,UNISTR(""));
return;
}
"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 */
VAR_UNREFER(cgVar);
varobjCreateMemberAs(call,args->data.object_val,name,cgVar,0);
}
else
{
/* regular parameter, make copy of the data */
Var tmp =
VAROBJ_CREATE_MEMBER(call,args>data.object_val,name,VUndefined);
VAR_COPY(tmp,cgVar);
/* and have stack var point to that data */
VAR_REFER(call,cgVar,tmp);
}
}
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,
(strlen_jsechar(src)+10)
*sizeof(jsechar));
strcpy_jsechar(FullFileName,src);
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.)
#if JSE_ALWAYS_COLLECT==1
ASSERT_VALID_VAR( relvar );
#endif
if( VAR_ARRAY_POINTER(relvar) )
{
if( relvar->data.string_val.data->constant!=0 )
MakeDuplicate(call,relvar);
VAR_COPY(dest,relvar);
dest->data.string_val.loffset += offset;
}
else
{
VAR_COPY(dest,relvar);
}
/* 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.)
Fix:
In call.c:183 function callLocalFunction(): Old
lines 183 and 184 used VAR_INIT_UNDEFINED, change
that to:
VAR_MAKE_VALID(&(call->returnval));
VAR_MAKE_VALID(&(call->funcStorage));
call.c:549 function callWrapperFunction(): Similar
change, so the line now reads:
VAR_MAKE_VALID(&(call->returnval));
util.c:717 function callInterpret(): Yet again
the same king of change:
VAR_MAKE_VALID(&(call->returnval));
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;
to:
struct Var *loc = stackPush(this);
Add right after the local variable declarations:
VAR_INIT_UNDEFINED(loc);
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:
STACK_DISCARD(this,1);
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;
to:
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.
Fix:
(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 ?
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"),
textcorevtype_null,
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);
callAddTempVar(call,var);
VAR_INIT_UNDEFINED(var);
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++ )
to:
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,
SRCCORE\VARUTIL.C
with
the code in -
ftp://ftp.nombas.com/pub/isdkeval/se420/bugfix.txt
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 -
vfscanf_jsechar(fp,
should
instead be -
vsscanf_jsechar(retbuf,
jseConstructObject
Problem:
jseConstructObject() may not call correct constructor
for objects with no explicit _construct property.
Fix:
Replace the function jseConstructObject() in file:
SRCMISC\SEOBJFUN.C
with
the code in:
ftp://ftp.nombas.com/pub/isdkeval/se420/bugfix.txt
"-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:
Blob.put(buf,0x80000000,SWORD32);
return Blob.get(buf,0,UWORD32);
or
the following may falsely return -1
Blob.put(buf,-3,SWORD32);
return Blob.get(buf,0,SWORD32);
Fix:
in seblob.c, function blobGetByValue(), at about
line 796, change:
assert(blobUWORD16 == type ||
blobUWORD24 == type ||
blobUWORD32 == type );
to:
{
assert(blobUWORD16 == type ||
blobUWORD24 == type ||
blobUWORD32 == type );
}
and
a few lines later, change:
jsePutLong(jsecontext,dest,l);
to:
if ( !((-type) & 1) )
jsePutLong(jsecontext,dest,l);
else
jsePutNumber(jsecontext,dest,(jsenumber)(ulong)l);
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:
SRCCORE\JSELIB.C
with
the code in:
ftp://ftp.nombas.com/pub/isdkeval/se420/bugfix.txt
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);
STACK_DISCARD(call,1);
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.
Fixes:
- for Solaris: srccore/extlib.c line 582, add
right before the case for __JSE_UNUX__:
#elif defined(__sun__)
temphExtensionLib = dlopen(FullLibraryPath,
RTLD_LAZY|RTLD_GROUP);
-
for Irix:
all extlib makefiles changed the definition of
EXT_LINK_FLAGS
to:
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;
else
# 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:
else
{
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) )
{
VAR_INIT_NUMBER(var,val+delta);
}
else
{
VAR_INIT_NUMBER(var,val);
}
}
in
srclib/ecma/ecmamisc.c, line 164, add:
if( jseIsNaN(result) )
jseReturnNumber(jsecontext,result);
else
before:
jseReturnNumber(jsecontext,result*sign);
(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:
varmemValidateIndex(this->varmem,this->offset_or_createType,
1,False,False);
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
following:
static
void NEAR_CALL
DoWaitForReadLoop(struct tcpipInfo *ti)
{
#if defined(__JSE_WIN16__) || defined(__JSE_WIN32__)
MSG msg;
#endif
while( !ti->GotWmSocketReadReady
&&
!ti->GotWmSocketCloseReady
)
{
# if defined(__JSE_WIN16__) || defined(__JSE_WIN32__)
if( !GetMessage(&msg,0,0,0)
) return;
TranslateMessage(&msg);
DispatchMessage(&msg);
# elif defined(USE_MAC_WINSOCK)
NMIdle();
# endif
}
}
static void NEAR_CALL
WaitUntilReadyToRecv(struct debugMe *debugme,SOCKET
socket)
{
struct tcpipInfo *ti =
(struct tcpipInfo*)jseDbgInfo(debugme);
unsigned long non_blocking = 0;
DoWaitForReadLoop(ti);
ti->GotWmSocketReadReady = False;
ti->GotWmSocketCloseReady = False;
ioctlsocket(socket,FIONBIO,&non_blocking);
}
static void NEAR_CALL
WaitUntilReadyToSend(struct debugMe *debugme,SOCKET
socket)
{
struct tcpipInfo *ti = (struct
tcpipInfo*)jseDbgInfo(debugme);
unsigned long non_blocking = 0;
ti->GotWmSocketWriteReady = True;
ti->GotWmSocketCloseReady = False;
ioctlsocket(socket,FIONBIO,&non_blocking);
}
The function DoWaitForWriteLoop() may be commented
out or
removed from the code altogether.
SECode_Stack_Push
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:
SECODE_STACK_PUSH(CallerCall->Global->thestack,
functionFinishCall(this,CallerCall->pChildCall,
InputVariableCount,ThisVar));
should become this code:
VarRead
*ret;
ret = functionFinishCall(this,CallerCall->pChildCall,
InputVariableCount,
ThisVar)
SECODE_STACK_PUSH(CallerCall->Global->thestack,ret);
In secode.c line 2100 this code:
should be:
and a few lines below that this code:
should be:
ToolkitAppPrintError
- No-unicode
Problem: Our default ToolkitAppPrintError function
does not
handle Unicode.
Fix: The single statement in PRINTERR.C
should become:
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) )
callSetReasonToQuit(this,RememberReasonToQuit);
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.
Fix:
In srclib/ecma/ecmamisc.c, the function Ecma_eval.
Right before the 'if ( !jseInterpret(...' line,
the following should be added:
# if 0 != JSE_MULTIPLE_GLOBAL
jseSetGlobalObject(jsecontext,
jseGlobalObject(jsePreviousContext(jsecontext)));
# 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) \
&& (JSE_HTML_COMMENT_STYLE==1)
if( src[0]=='<'
&& src[1]=='!'
&& src[2]=='-' && src[3]=='-' )
{
goto EndOfSourceLine;
}
else
#endif
Documentation
errata
4.20
documentation
-- (Jan. 5, 2000)
The
following corrections are all for functions documented
in the API Chapter.
jseMemberWrapperFunction
- 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.
jseInterpInit()
- 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.
|
