[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