Hint: Conversion between ordinals and pointers is not portable

[440bx]

Hello,

I understand _some_ of the cases when the compiler issues the hint (in the thread title), but there is at least one case where it does not seem to be applicable, specifically, in the case:

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

1. if ptruint(SomePointer) = ptruint(0) then ...

In that case, ptruint is guaranteed (?) by the compiler to be an unsigned integer of the size of a pointer regardless of platform, therefore, it seems the hint in that case is not applicable since that statement should be portable.

Am I missing something here ?

Thank you for your help.

[KodeZwerg]

it seems the hint in that case is not applicable since that statement should be portable.

I do full agree, this message should be either more specific (not portable to where?) or not shown at all.

[MarkMLl]

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

1. if ptruint(SomePointer) = ptruint(0) then ...

You need to show the EXACT error message, and investigate PRECISELY where in the statement to problem is.

Your use of ptruint(SomePointer) suggests that ptruint is happy casting a pointer. But in your second ptruint() the parameter is zero, and my suspicion is that internally it's casting this to nil before applying the explicit cast.

So what the compiler's objecting to is your implicit conversion between zero and nil, not your explicit casts.

MarkMLl

[440bx]

You need to show the EXACT error message, and investigate PRECISELY where in the statement to problem is.

the EXACT error message is in the title of the thread.  As far the "PRECISELY" goes, there is only one place where a conversion from pointer to ordinal occurs, that settles the precision concern.

Your use of ptruint(SomePointer) suggests that ptruint is happy casting a pointer.

No, on the contrary, the message "suggests" it is not happy at all about that.

But in your second ptruint() the parameter is zero, and my suspicion is that internally it's casting this to nil before applying the explicit cast.

IF the compiler is internally casting the zero to nil then it is hallucinating because there is no reason to cast the zero to nil and then cast that back to ptruint.  The compiler is most definitely _not_ doing that.

So what the compiler's objecting to is your implicit conversion between zero and nil, not your explicit casts.

No, it is not complaining about that and there is no implicit conversion of zero to nil in that statement.  That statement, unnecessarily, casts zero to ptruint (which causes no harm and is totally superfluous.)  If you need to convince yourself, remove the ptruint cast of zero and you'll see the same "hint" come up.

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

1. {$APPTYPE CONSOLE}
2.  
3. program ConversionHint;
4.  
5. var
6.   Somepointer : pointer;
7.  
8. begin
9.   SomePointer := @Somepointer;  { remove "doesn't seem to be initialized..."  }
10.  
11.   if ptruint(SomePointer) = ptruint(0) then
12. end.              

[MarkMLl]

the EXACT error message is in the title of the thread.  As far the "PRECISELY" goes, there is only one place where a conversion from pointer to ordinal occurs, that settles the precision concern.

(a) FPC outputs a line and character position for an error message. (b) The error you've quoted is for a conversion between an ordinal and pointer, not a pointer and ordinal.

Using 3.2.2 I can't compile it on Linux without removing that apptype, and when I do there's no error.

MarkMLl

[440bx]

Using 3.2.2 I can't compile it on Linux without removing that apptype,

I hope that wasn't too much work.

and when I do there's no error.

that is interesting because I get that error in both, FPC v3.0.4 and FPC 3.2.2 when using Lazarus to compile.  In the interest of exactness and precision, attached is a screenshot of the message window.

[MarkMLl]

No work but possibly results in different compiler behaviour.

Right, so line 11 character 6 which hopefully matches the listing you posted earlier, so it's the first conversion in

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

1.   if ptruint(SomePointer) = ptruint(0) then
2. /////^
3.  

so I was wrong assuming it was the ptruint(0) (which was not an unreasonable assumption from what you'd posted to that point).

So the interesting question is whether it's ptruint() objecting to being asked to cast something that is already a pointer, or an implicit conversion of the pointer to an integer before it tried.

MarkMLl

[440bx]

So the interesting question is whether it's ptruint() objecting to being asked to cast something that is already a pointer, or an implicit conversion of the pointer to an integer before it tried.

since ptruint is an unsigned integer of the same size as the platform's pointer, I don't see the reason why such a "conversion" would not be portable (there is no conversion taking place, just a different interpretation of the bytes involved.)  It should be portable which in turn means, the message emitted by the compiler doesn't apply to that case (or any other case where a pointer is being typecast using ptruint.)

OTOH, if the typecast had been to DWORD or QWORD then the message would definitely be appropriate because there is no guarantee from the compiler that a pointer is the same size as either one of those integer types.

[MarkMLl]

There's too much speculation in there, we probably need @PascalDragon to tell us what's really going on.

In any event, I can't duplicate it on Linux and it might depend on that apptype directive... which was actually resulting in an error rather than being ignored.

MarkMLl

[440bx]

There's too much speculation in there, we probably need @PascalDragon to tell us what's really going on.

I agree that it would very nice if @PascaDragon would shed light on the subject.  That said, there is no speculation in what I stated in the above post.  ptruint is _documented_ as being an integer of the same size as a pointer.

[MarkMLl]

I agree that it would very nice if @PascaDragon would shed light on the subject.  That said, there is no speculation in what I stated in the above post.  ptruint is _documented_ as being an integer of the same size as a pointer.

But there is speculation- on both our parts- as to whether the problem is at the explicit ptruint() cast or an implicit manipulation of the parameter. Since- I believe- a cast is an intrinsic, it's unclear what types of parameters it's happy with.

MarkMLl

[PascalDragon]

The thing is that PtrUInt (or PtrInt or NativeUInt or NativeInt) is not an internal type, but instead declared as an ordinary alias in the System unit for the corresponding size depending on the platform. Thus if you're compiling for e.g. a 32-bit platform your code in fact reads as

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

1. if LongWord(SomePointer) = LongWord(0) then ...

Thus you again have a fixed width ordinal type and thus the warning is issued.

[440bx]

Thus if you're compiling for e.g. a 32-bit platform your code in fact reads as

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

1. if LongWord(SomePointer) = LongWord(0) then ...

Thus you again have a fixed width ordinal type and thus the warning is issued.

Now it makes sense and, since that is how it does it, I don't see a way to avoid the hint.

[MarkMLl]

The thing is that PtrUInt (or PtrInt or NativeUInt or NativeInt) is not an internal type, but instead declared as an ordinary alias in the System unit for the corresponding size depending on the platform. Thus if you're compiling for e.g. a 32-bit platform your code in fact reads as

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

1. if LongWord(SomePointer) = LongWord(0) then ...

Thus you again have a fixed width ordinal type and thus the warning is issued.

So bearing in mind that we were discussing casts a few days ago, are there any intrinsic casts that might be applied to a pointer in an attempt to make it an acceptable parameter to LongWord() above or are pointers fundamentally immune to that?

What is the preference of e.g. PtrUInt() as far as its parameter is concerned? I'm just trying to get my head around what intrinsic casts might possibly get applied.

MarkMLl

[PascalDragon]

The thing is that PtrUInt (or PtrInt or NativeUInt or NativeInt) is not an internal type, but instead declared as an ordinary alias in the System unit for the corresponding size depending on the platform. Thus if you're compiling for e.g. a 32-bit platform your code in fact reads as

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

1. if LongWord(SomePointer) = LongWord(0) then ...

Thus you again have a fixed width ordinal type and thus the warning is issued.

So bearing in mind that we were discussing casts a few days ago, are there any intrinsic casts that might be applied to a pointer in an attempt to make it an acceptable parameter to LongWord() above or are pointers fundamentally immune to that?

What is the preference of e.g. PtrUInt() as far as its parameter is concerned? I'm just trying to get my head around what intrinsic casts might possibly get applied.

These are no functions or intrinsics, thus there are no parameters. These are type casts and a type cast has a right hand side (which is what is inside the parentheses) and a left hand side (which is the resulting type). And a Pointer can already be cast to LongWord (though you'll loose 32 bits on a 64-bit system) no intrinsics beside the type cast needed. It's just that the compiler will always issue a message in that case (a warning if the sizes don't match, a hint otherwise), because before the introduction of 64-bit systems many people used LongWord (or LongInt) and thus these people need to be made aware that something might be fishy in their code.