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

[Rhys Weatherley]

On Friday 24 September 2004 01:56 pm, Peter Colson wrote:

> Do these 'pointers' then get used as real pointers that point to
> structures defining the class or complex type? I would guess they do?

Yes.  Once the tag bits have been stripped, they are normal pointers again.

> But if the ILType* is sourced from a function like ILMetaUncompressData
> that returns a 4 byte unsigned long (which is one example I've seen) do
> we then have a problem on a platform using 8 byte pointers when (if) we
> need to use the ILClass* or ILComplexType* as a 'real' pointer?

If you look at any code that deals with types, you'll see sequences like this:

    if(ILType_IsPrimitive(type))
    {
        do something with ILType_ToElement(type);
    }
    else if(ILType_IsClass(type))
    {
        do something with ILType_ToClass(type);
    }
    else if(ILType_IsValueType(type))
    {
        do something with ILType_ToValueType(type);
    }
    else
    {
        do something with type as a complex type (the tag bits are
        zero in this case, so don't need to be stripped);
    }

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.

> 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.

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.

Cheers,

Rhys.