1. bug in SOMETHING?!
I have code a bit like this
a=allocate_string("blah")
err=c_func(functionname,{a}) --err<0 on error, 0 on success
free(a)
The code works fine on my Celeron/433 running Windows 98, whatever I do. It
works fine on my Windows 95 486-SX/50 too - unless I bind it with shrouding
enabled. err then shows an error. However, if I then comment out the
free(a) line, err shows success.
Now why should this be? Euphoria seems to be executing the third line
before the second in some circumstances.
So I forced the program to check that functionname had been executed by
checking for the value of err before freeing a:
a=allocate_string("blah")
err=c_func(functionname,{a})
if err then end if --check value of err
free(a)
and everything works fine. But this has taken days to track down.
So is this a bug in
a) my code
b) Euphoria
c) Windows 95
d) the 486 chip
e) something else?
chrissy.
2. Re: bug in SOMETHING?!
- Posted by euman at bellsouth.net
Feb 11, 2002
Hey chrissy,
if your functionname happens to call on a .dll version that
doesnt support the function then this could definatly be the problem.
Comctl32.dll gives the most trouble 'cause many common controls
that are used today werent available when 95 came out.
"Just a thought"
What's the function name?
Euman
euman at bellsouth.net
Q: Are we monetarily insane?
A: YES
----- Original Message -----
From: <tubby.toast at ntlworld.com>
To: "EUforum" <EUforum at topica.com>
>
> I have code a bit like this
>
> a=allocate_string("blah")
> err=c_func(functionname,{a}) --err<0 on error, 0 on success
> free(a)
>
> The code works fine on my Celeron/433 running Windows 98, whatever I do. It
> works fine on my Windows 95 486-SX/50 too - unless I bind it with shrouding
> enabled. err then shows an error. However, if I then comment out the
> free(a) line, err shows success.
>
> Now why should this be? Euphoria seems to be executing the third line
> before the second in some circumstances.
>
> So I forced the program to check that functionname had been executed by
> checking for the value of err before freeing a:
>
> a=allocate_string("blah")
> err=c_func(functionname,{a})
> if err then end if --check value of err
> free(a)
>
> and everything works fine. But this has taken days to track down.
>
> So is this a bug in
> a) my code
> b) Euphoria
> c) Windows 95
> d) the 486 chip
> e) something else?
>
> chrissy.
3. Re: bug in SOMETHING?!
- Posted by euman at bellsouth.net
Feb 11, 2002
Hey again chrissy,
nevermind, I re-read the post and you say that err returns success.
hmmm, interesting problem.
Have you turned type_checking on?
Euman
euman at bellsouth.net
4. Re: bug in SOMETHING?!
- Posted by rforno at tutopia.com
Feb 11, 2002
For your information, I discovered years ago a near-bug in the 486. Some
programs (an old version of APL, an Italian file compression program whose
name I don't remember at this very moment, and an old version of PCGLOBE)
ran OK on a 286, but failed on a 486. (The 386 had a similar problem, but it
didn't show in these programs). The reason is as follows: the programs
contained instructions that modified other instructions ahead. But in the
486, the modified instructions were already cached in the processor, and
then ran in unmodified state. This bug was removed in the Pentium. The
following is a small Assembler program that gives a correct result in a
Pentium and a wrong one in a 486. You may test several alternatives by
adding or removing 'and ax,ax' instructions between the modifying and the
modified instructions. I assembled the program with Borland Turbo Assembler
version 2.0.
.MODEL small
.STACK 100h
.DATA
Message DB 'Result is '
Result1 DB ?
Result2 DB ?
DB '; should be 05'
DB 13,10,'$'
.CODE
Start:
mov ax,@data
mov ds,ax
mov bh,0
mov cs:BYTE PTR modif+1,5
and ax,ax
and ax,ax
modif:
mov bl,0
add bl,'0'
add bh,'0'
mov Result1,bh
mov Result2,bl
mov dx,OFFSET Message
mov ah,9
int 21h
mov ah,4ch
int 21h
END Start
----- Original Message -----
From: <tubby.toast at ntlworld.com>
To: "EUforum" <EUforum at topica.com>
Sent: Monday, February 11, 2002 5:01 PM
Subject: bug in SOMETHING?!
>
> I have code a bit like this
>
> a=allocate_string("blah")
> err=c_func(functionname,{a}) --err<0 on error, 0 on success
> free(a)
>
> The code works fine on my Celeron/433 running Windows 98, whatever I do.
It
> works fine on my Windows 95 486-SX/50 too - unless I bind it with
shrouding
> enabled. err then shows an error. However, if I then comment out the
> free(a) line, err shows success.
>
> Now why should this be? Euphoria seems to be executing the third line
> before the second in some circumstances.
>
> So I forced the program to check that functionname had been executed by
> checking for the value of err before freeing a:
>
> a=allocate_string("blah")
> err=c_func(functionname,{a})
> if err then end if --check value of err
> free(a)
>
> and everything works fine. But this has taken days to track down.
>
> So is this a bug in
> a) my code
> b) Euphoria
> c) Windows 95
> d) the 486 chip
> e) something else?
>
> chrissy.
>
>
>
>
5. Re: bug in SOMETHING?!
Hi chrissy,
----------
> Îò: tubby.toast at ntlworld.com
> Êîìó: EUforum <EUforum at topica.com>
> Òåìà: bug in SOMETHING?!
> Äàòà: Monday, February 11, 2002 23:01
> I have code a bit like this
>
> a=allocate_string("blah")
> err=c_func(functionname,{a}) --err<0 on error, 0 on success
> free(a)
>
> The code works fine on my Celeron/433 running Windows 98, whatever I do.
It
> works fine on my Windows 95 486-SX/50 too - unless I bind it with
shrouding
> enabled. err then shows an error. However, if I then comment out the
> free(a) line, err shows success.
>
> Now why should this be? Euphoria seems to be executing the third line
> before the second in some circumstances.
>
> So I forced the program to check that functionname had been executed by
> checking for the value of err before freeing a:
>
> a=allocate_string("blah")
> err=c_func(functionname,{a})
> if err then end if --check value of err
> free(a)
>
> and everything works fine. But this has taken days to track down.
>
> So is this a bug in
> a) my code
> b) Euphoria
> c) Windows 95
> d) the 486 chip
> e) something else?
>
> chrissy.
486-SX chips give no access to floating point component (FPU)
on the crystal, so your problem may be solved, it seems to be,
if you'll try the following command in AUTOEXEC.BAT:
SET NO87=1
Just add this line into your AUTOEXEC.BAT file and reboot your
machine. Then EU will use software floating point functions.
A 486-DX has normal FPU (compatible with 80387 commands).
[AS IS. Without Warranty]
Good luck!
Regards,
Igor Kachan
kinz at peterlink.ru
6. Re: bug in SOMETHING?!
> Have you turned type_checking on?
>
> Euman
I turned type_checking off as I always do before binding. I though it was
only really necessary for debugging. But I turned it back on, bound it
and...hey! It works! Ok, I'll leave type_check on then. But why does this
fix the problem?
Thanks to everyone who tried to help.
chrissy.
