OpenEuphoria

RE: poke4 won't accept my 32bit values

• Posted by Chris Bensler <bensler at mailops.com> Mar 21, 2001
• 498 views

Thank you Rob,

  I fixed that bug..
instead of poking all four bytes, I changed it to only poke the first 
two bytes from int_to_bytes.. This works with Safe.e

But like you said, after this fix, the system hangs on Safe.e
When I run the fixed demo with Machine.e, I get the same error..

poke4 is limited to 32-bit numbers

I think what you found was just ANOTHER bug, not the one I'm trying to 
solve..


Todd, you should update that lib.. for the poke_words fix


Chris


Robert Craig wrote:
> Chris:
> I finally got around to trying your program.
> 
> Since you aren't using Win32Lib,
> I tried your program using safe.e in place 
> of the regular machine.e.
> 
> I did the following:
> 
>       copy \euphoria\include\safe.e .
>       rename safe.e machine.e
> 
> Then I ran Derek's "working demo.exw".
> 
> After a few seconds safe.e reported a call 
> to poke() that is poking out of bounds, and it gave
> me an ex.err dump (attached).
> 
> Here's what's happening.
> 
> In poke_words() in exotica_api.ew
> you have a loop that is poking values.
> On the final iteration of the loop you (or Todd?) are
> stepping out of bounds. Although you are
> storing 2-byte values, you are actually poking
> 4-bytes at a time (from int_to_bytes()), while 
> advancing the address only by 2. 
> This is strange, but it works, except
> that on the final iteration you write 2 bytes
> out of bounds. pwCubeIndices is allocated a block
> that's 2-bytes too small. I gave it a couple of extra
> bytes and the safe.e report went away. However,
> I think I have an old version of directx, so my system
> hangs beyond that point.
> 
> What does this have to do with poke4 and FFFFFFFF?
> Well, the interpreter can't store FFFFFFFF as a 
> Euphoria 31-bit integer, so it allocates a place in the heap
> memory for a double. It's just possible that you are
> overwriting this double, thereby changing the value
> of this literal "constant" in the program.
> Any change to the program, such as shuffling statements
> around, do things in a slightly different way, could possibly
> change what is stored just after your block of memory,
> and could make the program either work or not.
> This naturally leads to all sorts of wild theories as
> to what might be happening.
> 
> Anyway, fix this bug and carry on.
> There may be other bugs. I can't tell.
> 
> Regards,
>    Rob Craig
>    Rapid Deployment Software
>    http://www.RapidEuphoria.com
> 
>