RE: poke4 won't accept my 32bit values
- Posted by Chris Bensler <bensler at mailops.com> Mar 21, 2001
- 499 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 > >