Re: 64-bit blues
- Posted by mattlewis (admin) May 24, 2012
- 1180 views
I've run into a couple of problems converting to 64-bit Euphoria: The first, I've solved myself; the second is beyond my skill level.
Stats: Euphoria Interpreter v4.1.0 development 64-bit Linux, Using System Memory Revision Date: 2011-06-30 16:06:49, Id: 5038:3739d931e005
You've got a pretty old version. The latest eubin (13MB) is from April 25th of 2012. I suspect that updating would solve this issue for you.
Do we already have a CPU_64 defined somewhere, otherwise, how best to determine this?
There are several new ifdefs, though none are actually required. You can use sizeof( C_POINTER ) and poke_pointer() / peek_pointer() for dealing with pointers portably. The new ifdefs are:
- BITS32 / BITS64
- X86 / X86_64 / ARM
- LONG32 / LONG64 - the size of a native C "long int" on this platform
Problem passing pointers via c_func/c_proc?
SET: Cairo_t property: 'fill_rule'
Expects: Ptr Int
Returns: Nul
Vector: 114
ARGS: {2604572528,0} -- first arg is the handle
/home/irv/demos/GtkEngine.e:494 in function set()
A machine-level exception occurred during execution of this statement (signal 11)
The call at line 494 is: c_proc(method[VECTOR],args)
The same programs work perfectly when running 32-bit Eu, but there the handles never exceed 9 digits.
Further testing shows that both c_proc and c_func cause an exception whenever the handle passed to them looks too large; greater than 1_000_000_000 apparently.
This happens 100% of the time with test60.ex or any program which creates a Cairo object, and unreliably at random times with other controls.
What to do?
Make sure that the parameter is defined as C_POINTER. In general, use the best match for whatever the C prototype is. Note that some of the C_* constants are different than in 4.0, because they actually refer to different things when you go to a 64-bit architecture.
Matt
