How to resolve "Conversion between ordinals and pointers"

[Thaddy]

If you're sure of what you're doing just surround the code with:

Code: Pascal  [Select][+][-]

1. {$HINTS OFF}{$WARNINGS OFF}
2. (**)
3. {$HINTS ON}{$WARNINGS ON}

Nope, don't do that!, do:

Code: Pascal  [Select][+][-]

1. {$push}
2. {$hints off}{$warnings off}
3. .....
4. {$pop}
5.  

Because you can't be sure of the current compiler settings for the code.
You CAN use it if your code needs to be compiled in Delphi too, though.
But if you go for FPC, use push/pop. That is more correct and cleaner. You don't want to inadvertently set something on that is already off....

[Thaddy]

In general it should also be of note that libraries that use untyped pointers that are really just pointers of the native size and therefor typed/typeable need to be refactored to use that native size. That also makes the warning disappear. So you may want to ask the maintainers of that library to update their sources to reflect more modern pascal.

[guest58172]

Nope, don't do that!, do:

Code: Pascal  [Select][+][-]

1. {$push}
2. {$hints off}{$warnings off}
3. .....
4. {$pop}
5.  

Clear, it's much better.

[eny]

IIRC Delphi uses more NativeInt and NativeUint, as they were introduced in XE2. The basic problem is that a good name for this quickly becomes too verbose.
Personnaly I think that SystemInt would had been a better choice since that's even not the hardware that defines this. Native is ambiguous.

That is exactly the point: PtrUint implies some sort of pointer type when in fact it is an integer type: it is non-intuitive.
A non-descriptive name is better than a descriptive name that implies one thing, but actually does something else, because it forces you to dive into the documentation.

'Too verbose': well this is Pascal, not C(++/#) 
Something like 'PtrAsUInt' or 'PtrToUInt' or 'Ptr2UInt' or 'PtrAsNativeInt' would have been better choices.
But I guess at the time this was invented most of the developers still had a C-ish background, hence the erroneous name.
Water under the bridge...

If you're sure of what you're doing just surround the code with:

Code: Pascal  [Select][+][-]

1. {$HINTS OFF}{$WARNINGS OFF} ...

In this particular case TS would have gotten the completely wrong values because he was trying to cast a pointer value to an integer value and not the value the pointer was referring to.
Or possibly a segmentation fault.

[taazz]

A non-descriptive name is better than a descriptive name that implies one thing, but actually does something else, because it forces you to dive into the documentation.
'Too verbose': well this is Pascal, not C(++/#) 
Something like 'PtrAsUInt' or 'PtrToUInt' or 'Ptr2UInt' or 'PtrAsNativeInt' would have been better choices.

NO! HELLL NO! nice names for functions but this is a type it does not cast or convert anything. And it is used for more than casting. As for NativeInt native to what? The hardware? The software? No UIntPtr or PtrUInt are good if you want something more verbose then something along the lines of PointerSizedUnsignedInteger would be a complete and accurate name.

[eny]

NO! HELLL NO!

YES! HEAVEN! YES!

this is a type it does not cast or convert anything...

Eh.... http://lazarus-ccr.sourceforge.net/fpcdoc/ref/refse46.html#x92-990009.4

No UIntPtr or PtrUInt are good

They are not, as was already explained above.

if you want something more verbose then something along the lines of PointerSizedUnsignedInteger would be a complete and accurate name.

Again, water under the bridge.
No one is asking to change anything (well, in these names anyways).

[Zaher]

If you're sure of what you're doing just surround the code with:

Code: Pascal  [Select][+][-]

1. {$HINTS OFF}{$WARNINGS OFF}
2. (**)
3. {$HINTS ON}{$WARNINGS ON}

I used that way before, but I want a standard way.

[Thaddy]

If you're sure of what you're doing just surround the code with:

Code: Pascal  [Select][+][-]

1. {$HINTS OFF}{$WARNINGS OFF}
2. (**)
3. {$HINTS ON}{$WARNINGS ON}

I used that way before, but I want a standard way.

Yes, but the standard and clean way depends on the library code avoiding untyped pointers.
It is simply not always possible to do without changing that library code.

In the first example this would be the cleanest I can think of:

Code: Pascal  [Select][+][-]

1. function RangeToProcessor(Range: PtrUINT): Byte;
2. begin
3.   Result := byte(Range);
4. end;  
5.  

[Zaher]

Code: [Select]

Yes, but the standard and clean way depends on the library code avoiding untyped pointers.

I agree but the pointer is from the base class that i cant change it, I think hint off for it the best solutuion

[Thaddy]

In that case use my push/pop solution.