updating oE poke_long


<built-in> procedure poke_long(atom addr, object x) 

stores one or more integers, starting at a memory location.

  1. addr : an atom, the address at which to store
  2. x : an object, either an integer or a non empty sequence of double words.

Poking in memory you do not own may be blocked by the OS, and cause a machine exception. If you use the define safe these routines will catch these problems with a Euphoria error.


There is no point in having poke_longs or poke_longu. For example, both +power(2,31) and -power(2,31) are stored as #F0000000 on a 32-bit architecture. It is up to whoever reads the value to figure it out.

On all Windows and other 32-bit operating systems, the poke_long uses 4-byte integers. On 64-bit architectures using operating systems other than Windows, poke_long uses 8-byte integers.

It is faster to write several integers at once by poking a sequence of values, than it is to write one double words at a time in a loop.

The 4-byte (or 8-byte) values to be stored can be negative or positive. You can read them back with either peek_longs or peek_longu. However, the results are unpredictable if you want to store values with a fractional part or a magnitude greater than the size of a native long int, even though Euphoria represents them all as atoms.

Example 1:
 a = allocate(100)   -- allocate 100 bytes in memory 
-- poke one 4-byte value at a time (on Windows or other 32-bit operating system): 
poke_long(a, 9712345) 
poke_long(a+4, #FF00FF00) 
poke_long(a+8, -12345) 
-- poke 3 long int values at once: 
poke_long(a, {9712345, #FF00FF00, -12345}) 
See Also:

Using Data Double Words, peek4s, peek4u, poke, poke2, allocate, free, call

Not Categorized, Please Help


Quick Links

User menu

Not signed in.

Misc Menu