Are pointers normalized before comparison

[joho]

Sorry if use the wrong term here, and possibly because some target environments may not suffer from this, but:

Does the compiler normalize all pointers before doing comparisons?

p1, p2 :pointer;

p1 := @p1block;
p2 := @p2block;

if (p1 > p2) then ...

Or do I have to cast them to something (and possibly something unsigned too?)

[Eugene Loza]

I'm not exactly sure what are you trying to achieve. But in your example everything should work fine for both local and global variables, as "pointers" are 64-bit (32-bit on 32-bit platforms) integers referencing to a memory address. If you need to get a numeric of the pointer you can easily LongWord(aPointer) it. However, as I've said, it's just an integer, so you can simply do inc(aPointer,4) to increase aPointer by 4 bytes (very useful). E.g. you can even if (p1 > p2+1024) then ...
See also https://www.freepascal.org/docs-html/ref/refse15.html . The program PointerArray; example looks like it.

[Leledumbo]

However, as I've said, it's just an integer, so you can simply do inc(aPointer,4) to increase aPointer by 4 bytes.

Watch out, that applies only for untyped pointer or pointer of something of byte size. In other cases, Inc() increases as much as the size of type the pointer points to. e.g.:

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

1. var
2.   p: PByte;
3.   q: PLongWord;
4. begin
5.   PtrUInt(p) := $1111111111111110;
6.   PtrUInt(q) := $1111111111111110;
7.   Inc(p,4);
8.   Inc(q,4);
9.   WriteLn(HexStr(PtrUInt(p),SizeOf(p) * 2));
10.   WriteLn(HexStr(PtrUInt(q),SizeOf(q) * 2));
11. end.
12.  

output:

Code: [Select]

1111111111111114
1111111111111120


[joho]

Sorry if I was unclear ... what I meant is if it's save to assume that the compiler does *unsigned* pointer arithmetics (when it comes to comparing pointers)? Or do I have to cast them as CARDINAL or similar? For a ring buffer, I need to know where the current position is, and where the head and tail is. So if these are signed comparison, there is a (theoretical) chance that a signed comparison would barf, no?

[munair]

Normally, when you access data in a buffer, you just point to the position of whatever data structure you use and memory access will be handled for you. And if you shift the data up or down the buffer, addresses will be updated when needed.

[munair]

You can also set up a data structure and include a position variable. This will give you complete control over the number of elements, which one is first or last, and you can change/shift them at will. But this is just an example, since I do not know what kind of data you are talking about.

[marcov]

Sorry if I was unclear ... what I meant is if it's save to assume that the compiler does *unsigned* pointer arithmetics (when it comes to comparing pointers)? Or do I have to cast them as CARDINAL or similar?

Yes, it should be safe for unsigned pointers in 32-bit and 64-bit memory flat models.

In segmented models (16-bit x86) everything is different.

[ASerge]

Sorry if I was unclear ... what I meant is if it's save to assume that the compiler does *unsigned* pointer arithmetics

Pointer arithmetics is signed:

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

1. {$APPTYPE CONSOLE}
2. program Project1;
3.  
4. var
5.   A, B: Integer;
6. begin
7.   Writeln(PtrInt(@A) - PtrInt(@B));
8.   Writeln(@A - @B);
9.   Writeln(PtrUInt(@A) - PtrUInt(@B)); // Wrong
10.   Readln;
11. end.

Code: [Select]

-4
-4
18446744073709551612

[engkin]

Sorry if I was unclear ... what I meant is if it's save to assume that the compiler does *unsigned* pointer arithmetics

Pointer arithmetics is signed:

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

1. {$APPTYPE CONSOLE}
2. program Project1;
3.  
4. var
5.   A, B: Integer;
6. begin
7.   Writeln(PtrInt(@A) - PtrInt(@B));
8.   Writeln(@A - @B);
9.   Writeln(PtrUInt(@A) - PtrUInt(@B)); // Wrong
10.   Readln;
11. end.

Code: [Select]

-4
-4
18446744073709551612

The results here are different:

-16
-16
-16

[mse]

Sorry if use the wrong term here, and possibly because some target environments may not suffer from this, but:

Does the compiler normalize all pointers before doing comparisons?

Yes.

p1, p2 :pointer;

p1 := @p1block;
p2 := @p2block;

if (p1 > p2) then ...

Or do I have to cast them to something (and possibly something unsigned too?)

No.

[ASerge]

The results here are different:

-16
-16
-16

1. The first and second lines show that the arithmetic is signed.
2. In the 32 compiler, if the result does not fit in 32 bits, but is fit in Int64, then it will be Int64, for compatibility. Use the additional PtrUInt (Result).

[engkin]

The results here are different:

-16
-16
-16

1. The first and second lines show that the arithmetic is signed.
2. In the 32 compiler, if the result does not fit in 32 bits, but is fit in Int64, then it will be Int64, for compatibility. Use the additional PtrUInt (Result).

Thank you.

[taazz]

The results here are different:

-16
-16
-16

1. The first and second lines show that the arithmetic is signed.

no it only shows that you asked the compiler to treat it as a signed integer by type casting it to one.

2. In the 32 compiler, if the result does not fit in 32 bits, but is fit in Int64, then it will be Int64, for compatibility. Use the additional PtrUInt (Result).

erm you lost me here, there is no way in a 32bit application a pointer will ever be treated as a 64bit.
Your example is wrong in all counts, mostly because you force a specific translation of the data.

[ASerge]

no it only shows that you asked the compiler to treat it as a signed integer by type casting it to one.

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

1. Writeln(@A - @B);

And where is the cast?

there is no way in a 32bit application a pointer will ever be treated as a 64bit.

After casting this integer computation. Compile this in 32 bit

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

1. {$APPTYPE CONSOLE}
2. program Project1;
3.  
4. var
5.   A, B: Cardinal;
6. begin
7.   A := 1;
8.   B := 2;
9.   Writeln(A - B);
10.   Readln;
11. end.

This from assemble code (the compiler selects 64-bit arithmetic for 32-bit types):

...
   movl   %eax,%ebx
   movl   U_$P$PROJECT1_$$_A,%esi
   movl   $0,%eax
   movl   U_$P$PROJECT1_$$_B,%edx
   movl   $0,%ecx
   subl   %edx,%esi
   sbbl   %ecx,%eax
   pushl   %eax
   pushl   %esi
   movl   %ebx,%edx
   movl   $0,%eax
   call   fpc_write_text_int64
   call   FPC_IOCHECK
...

Your example is wrong in all counts

Your message is wrong in all counts 

[munair]

Why would pointers be negative in today's flat memory model? The only experience I had with negative addresses was with computer languages in 16 bit environments that did not support WORD data types. So addresses between 32768 and 65535 were automatically given as signed integers between -32768 and -1. The trick was to always "convert" to unsigned integers by adding 65536 and store them as long integers. It was dirty, but it worked. In today's flat memory models, pointers should support the unsigned range of the environment (32 or 64 bits).