dec (and likely inc) do not operate as in Delphi

[440bx]

Hello,

FPC returns an error when attempting to compile:

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

1. program AddressOfConstantError;
2. uses
3.   Windows
4.   ;
5.  
6. procedure DoIt;
7. var
8.   TabbedTextExtent      : integer;
9.   ClientRect            : TRECT;
10.  
11. begin
12.   ZeroMemory(@ClientRect, sizeof(ClientRect));
13.   ClientRect.Right := 8;
14.  
15.   TabbedTextExtent := 20;
16.    
17.   // below is the statement FPC does not like
18.  
19.   Dec(LOWORD(TabbedTextExtent), ClientRect.Right div 4);
20. end;
21.  
22. begin
23.   DoIt;
24. end.
25.  

with the error

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

1. AddressOfConstantError.lpr(22,55) Error: Can't take the address of constant expressions

Delphi compiles the program without complaint (it decrements the word at the address loword(variable)).  FPC will not compile the program even in Delphi mode.

Should this be considered a "Delphi compatibility mode" bug ?

[marcov]

Might also be a matter of loword not being a build in or so.

So if it is a buildin, it can be used in situations that ask an adress, or not.

You can always file it, but having some context is better (like is this in all Delphi versions so?)

[ASerge]

Delphi compiles the program without complaint (it decrements the word at the address loword(variable)).  FPC will not compile the program even in Delphi mode.

I tested in old (Delphi 7) and new (Delphi 10.3) - both give an error at compile time.

[440bx]

Might also be a matter of loword not being a build in or so.

So if it is a buildin, it can be used in situations that ask an adress, or not.

You can always file it, but having some context is better (like is this in all Delphi versions so?)

Based on the code the compiler (Delphi 2.0 - in my case) generated, it looks like the compiler "knows"/"calculates" the target address.

I don't know if that behavior is present in all versions of Delphi.  The only version I keep installed on my machine is Delphi 2.0. 

It would be nice if other people, who do have multiple versions of Delphi "on hand", could test the code I submitted and answer your question.

ETA:

@Serge:

Thank you for trying it out in other versions of Delphi.

ETA 2:

Given Serge's results, I don't think this behavior should be reported as a bug since it is not even consistent across versions of Delphi.

[jamie]

LOWORD is a function, its not a casting record.

quick look, it comes from the WINDOWS and has not been made to be a
macro

 casting it with a WORD should produce what you want but I don't know how that would be implemented
in fpc so not to use it as a type.

define LOWORD = WORD;

currently its a Function which Is why it is behaving this way.

[440bx]

currently its a Function which Is why it is behaving this way.

I understand why it's behaving that way. 

It's interesting that the Delphi 2 compiler simply adjusts the target address.  Very efficient... nice

[jamie]

You know I got thinking, yes I know its a dangerous thing to do.

Inc(Pword(@YourDwordOrLongword)[1], howmuch);


Just thinking..

[440bx]

You know I got thinking, yes I know its a dangerous thing to do.

Inc(Pword(@YourDwordOrLongword)[1], howmuch);


Just thinking..

For some reason, I don't really know why of course, that line of code reminds me of the C language.

I just overlaid a record definition over the dword breaking it into two variables, used the one in the loword as a parameter to inc.  The FPC compiler is happy to get a variable, Delphi 2.0 is happy either way and, I'm happy my variable got incremented.  The stuff binary fairy tales are made of.