Why does FPC behave this way? Maybe we should create an issue?

[ALLIGATOR]

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

1. program app;
2. {$mode objfpc}
3.  
4. var
5.   p1: Pointer = nil;
6.   p2: Pointer = nil;
7.   r: NativeInt;
8. begin
9.   r := p2 - p1; // OK
10.   r := p2 + p1; // Error
11. end.

As far as I'm concerned, either option should be OK, or both options should be Error

[Thaddy]

Delphi does not accept this at all:
[dcc32 Error] Project11.dpr(9): E2015 Operator not applicable to this operand type
[dcc32 Error] Project11.dpr(10): E2015 Operator not applicable to this operand type
It looks a bug.
Also: pointers are unsigned by nature, but that does not matter here..

[440bx]

As far as I'm concerned, either option should be OK, or both options should be Error

No.  What FPC does in those cases is what should be done.

The difference between two pointers is the distance between the addresses something which is often needed.

The addition of two pointers is meaningless, therefore the compiler is right in rejecting the addition.  That said, if for some reason it would be needed to carry out such an operation, simply typecast the second pointer to ptruint and the compiler will then interpret it as a distance instead of a pointer thereby allowing the operation (I've never needed to add two pointers... ever!... the result is meaningless and quite likely totally useless... cannot think of an example, not even a contrived one, where it might be useful)

Conclusion: the compiler is right.  Subtraction is logically sound.  Addition is meaningless, therefore rejected.

[Thaddy]

That leaves the small matter that Delphi does not accept both, although I think your reasoning is OK for mode objfpc.

[440bx]

That leaves the small matter that Delphi does not accept both, although I think your reasoning is OK for mode objfpc.

Delphi isn't always right (that said, it is much more often right than wrong.)

It's been a while since I used Delphi (Delphi 2 in my case) but, I remember taking the difference between two pointers in Delphi 2, what I don't remember is if I had to typecast the pointers for the operation to be allowed.

[ALLIGATOR]

...

Yes, that makes sense

[MarkMLl]

That leaves the small matter that Delphi does not accept both, although I think your reasoning is OK for mode objfpc.

That could be explained if Delphi does not attempt to use "The Delphi Language" to write low-level memory management code.

I remember a 1970s book called something like "Writing Linkers and Loaders", the title of which would suggest that it was oriented towards mainframes. This made the argument that integers and pointers were a fairly close parallel to scalars and vectors in that there were permissible and illegal combinations: you can index relative to a pointer by adding or subtracting an integer, you can meaningfully subtract (but not add) and compare pointers for equality, you can't multiply pointers... and so on.

So while subtraction of pointers might be one of those operations best inaccessible to application-level programmers, it's definitely needed.

MarkMLl

[Thaddy]

I agree that the distance between raw pointers is useful indeed.
I guess that part is intentional.

[simone]

If I remember correctly, even in C, subtraction between pointers is allowed, but addition is not.

[Thaddy]

Just tested D7: same errors, both + and - not accepted by Delphi. My previous post was test with D12.1

[440bx]

If I remember correctly, even in C, subtraction between pointers is allowed, but addition is not.

I remember successfully subtracting pointers in C.  I can't say anything about adding them because I've never needed that.

[Thaddy]

C (any flavor) will not accept the addition without casts.
C will accept the difference without cast, like FPC does.

[tetrastes]

I remember a 1970s book called something like "Writing Linkers and Loaders", the title of which would suggest that it was oriented towards mainframes. This made the argument that integers and pointers were a fairly close parallel to scalars and vectors in that there were permissible and illegal combinations: you can index relative to a pointer by adding or subtracting an integer, you can meaningfully subtract (but not add) and compare pointers for equality, you can't multiply pointers... and so on.

Fairly close parallel? For sure you can add and multiply vectors.

[Khrys]

Fairly close parallel? For sure you can add and multiply vectors.

Component-wise, scalar product or cross product? 

In any case, has anyone tried this with typed pointers in Delphi?
It's important to note that e.g.  PByte(A) - PByte(B) <> PInteger(A) - PInteger(B),  which is required to uphold the indexing identity  Ptr[Index] = (Ptr+ Index)^  (i.e. pointee size must be taken into account).

Since  void*  is an incomplete type and thus has no well-defined size, pointer arithmetic on  void*  is forbidden in C and C++.  Maybe Delphi is just following suit?

[440bx]

Actually, there is no good reason to disallow the subtraction of two plain/untyped pointers in Pascal.

A plain/untyped pointer is an address, the type it points to is unknown since it is untyped but, there is no doubt whatsoever that it is an address.   Subtracting two untyped addresses yields the number of memory units between those two addresses and, in today's computers, a memory unit is a byte. 

Therefore, the subtraction of two untyped pointers should yield the number of bytes between the two addresses.

The really important thing when subtracting pointers is that they MUST be of the same type, otherwise the subtraction is senseless. For instance, subtracting a pointer to a boolean from a pointer to a qword, makes no sense because the unit of distance between those pointers/addresses cannot be established.

In Pascal, an untyped pointer is the address of the minimum addressable memory unit, i.e, a byte, subtraction of such pointers should be allowed just as they are allowed on ^byte (since they are implicitly pointers to a byte.)

Note that in C, a void* is _not_ semantically identical to a Pascal untyped pointer because in C, there is the concept of a void item/object.  That does not exist in Pascal, i.e, there is no ^; (pointer to semicolon, which would be the Pascal "pointer to empty", overloading the semicolon to mean not only empty statement but "empty anything" (which is C's void))  IOW, by definition, in C a void* doesn't point to a byte instead it points into nothingness and it makes no practical sense to subtract nothingness from nothingness.  If C allowed the subtraction of two void* then the only possible result would be zero reqardless of their value because they both point to the same thing: nothing!