[Fwd: Re: [ODE] AMD64: OPCODE cast from 64 bits pointer to 32 bits
integer (patch included)]
Tanguy Fautre
tanguy.fautre at spaceapplications.com
Fri Feb 25 17:57:12 MST 2005
Since attachments don't go in the archive, you can find the patch at
http://users.telenet.be/tfautre/ode-0.5_OPCODE64.patch
-------- Original Message --------
Subject: Re: [ODE] AMD64: OPCODE cast from 64 bits pointer to 32 bits
integer (patch included)
Date: Fri, 25 Feb 2005 16:11:48 +0100
From: Tanguy Fautre <tanguy.fautre at spaceapplications.com>
Organization: Space Applications Services
To: ode at q12.org
Hi,
This morning I've been trying to get OPCODE and ODE to work correctly.
The idea here is to basically use size_t instead of udword where
integers are used to store pointers.
Because size_t is an unsigned int of 32 bits on 32 bits platforms and a
64 bits uint on 64 bits platforms, this modification should not affect
the performance nor the memory usage on 32 bits platforms.
I'm including a patch resulting from a diff of the whole OPCODE
directory. Btw, as crazy as it may sound, this is the first time I ever
use the linux diff command, so if the patch is not correct for one
reason or another, do not hesitate to tell me and I'll create another one.
I noted that there is also an invalid pointer to integer conversion in
ode source code. Located in the file collision_trimesh_trimesh.cpp, the
function GetTriangleGeometryCallback.
The variable user_data is a pointer and is converted to a udword, which
is *evil*. However I cannot locate the place where this function is used
in ODE; is it a left over?
Anyway, with this patch I'm able to use ODE on AMD64 with trimesh
collisions. I have not tested it back on a 32 bits Linux though.
Yours,
Tanguy
PS: second time I try to send this to the mailing list, the attachment
was too big apparently.
More information about the ODE
mailing list