[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pnet-developers] Use of ILNativeUInt vs. unsigned long in pointer c

From: Peter Colson
Subject: Re: [Pnet-developers] Use of ILNativeUInt vs. unsigned long in pointer casting and manipulation
Date: Fri, 24 Sep 2004 14:54:28 +1000

On 24/09/2004, at 2:05 PM, Rhys Weatherley wrote:

In all cases where ILMetaUncompressData is used, the result of
ILType_ToElement will be a simple integer again. There will never be a case where a "ILType *" is converted into a class pointer if it originated as a primitive element type. Besides fixing the "unsigned long" vs "ILNativeUInt" problem in il_types.h, there should be nothing more for you to worry about.

OK this makes sense too. I was beginning to realise that ILType_FromElement
results would never be used as pointers and this confirms it.

I'm just trying to see if there's a future porting pnet to an AS/400
platform that now allows for 8 byte pointers that can be bit manipulated
(but provides 4 byte longs).

In theory, it is possible. That's what ILInt32 vs ILInt64 vs ILNativeInt is for. Presumably you have some integer type (e.g. "long long") that can be defined as an 8-byte ILNativeInt and cast back and forth to pointer types
without loss of information.  Once you have that, you're set.

Yes we've got long long and ILNative[U]Int does indeed resolve to that.

There may be a few odd places where we have used "long" instead of
"ILNativeInt", but they aren't as prevalent as you think. Most other places where "long" is used in the code, the values it holds are assumed to be "at
least 32-bits", and are not pointer-related.

Good, that's what I was hoping.

Currently I've hit an error in cvm.c ReadLong where the stack pointer is
pointing to undefined memory. I wanted to make sure our pointers weren't
being blitzed in an avoidable way.

If you have any tips for debugging cvm.c, let me know. I'm finding it
difficult to debug into all the macros used in that module. I can see
_ILCVMInterpreter being entered, lots of macro/include action and
then failure in ReadLong (this is on the hello.exe sample).

The 400 compiler should be supporting this better, but seems to have
changed for the worse in that respect from V4 to V5. D'oh!

Peter Colson.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]