[Solved] Compiler allows un-indexed Array as Absolute argument- is this desired?

[Ten_Mile_Hike]

The code below is PURPOSELY INCORRECT.
The compiler allows it and interprets D to always be = to A[1]

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

1. procedure TForm1.Button1Click(Sender:TObject);
2. var
3.     A:Array[1..4] of Integer=(13,10,11,12);
4.     D:Integer Absolute A;  {Something like A[3] would be correct here, NOT A}
5. begin
6.     Button1.Caption := inttostr(D);  //Returns A[1] or "13" as the Button caption
7. end;      

My question is should the compiler be accepting "Absolute A" instead of the correct A[index] or
 should this produce an "Error" instead

[jamie]

what is not correct?

Looks like it's working correctly.

Why would you think otherwise? Maybe it's a different language you come across that does that.

[Martin_fr]

"Absolute" is not type safe. And it isn't meant to be afaik.  In fact it is often used as a way to access on variable as something of another type.

Often time, those "type translations" are such that they could be done by typecase (maybe pointer to TObject), but that isn't necessary.

You could have a record "TPoint = record x,y: integer; end". And if you know that "x" is the first thing in memory, and it is right at the start of the record, then you could have an integer variable "absolute" at an variable of type TPoint.

In other words, it just takes the address, and gets whatever is in memory.
so it would then do the same as

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

1. PInteger(@MyPoint)^

It does the same in your case.

You have a static array, and a static array is not a pointer, it is straight there in memory, like a record would be. So the address of the array "A" and the entry "A[1]" are the same.

Hence it works.
(It wouldn't work with a dynamic array)

[440bx]

My question is should the compiler be accepting "Absolute A" instead of the correct A[index] or
 should this produce an "Error" instead

in addition to what Jamie and Martin already said, the argument of "absolute" is a memory reference and "A" _is_ a memory reference, specifically it is where the array is located in memory, therefore it is _not_ an error.

As long as "absolute" is given a memory reference there is no problem.  You can even use the name of _typed_ constant (because a typed constant is actually a variable, thus a memory reference.)

HTH.

[Khrys]

The  absolute  keyword has assembler-level powers; any type/memory safety checks go straight out the window when using it. You can even use hard-coded addresses for  absolute  variables:

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

1. function Foo(): Integer;
2. var
3.   Bar: Integer absolute $DEADBEEF;
4. begin                // Compiles with no warnings
5.   Result := Bar;     // Equivalent to Result := PInteger(Pointer($DEADBEEF))^
6. end;

[TRon]

"Absolute" is not type safe. And it isn't meant to be afaik.  In fact it is often used as a way to access on variable as something of another type.

It is indeed not meant to be typesafe.

If it would then it would render the use of it useless and not compatible to its original implementation.

Therefor always handle the use of the absolute modifier with care when using it.

[jamie]

Real men program in Assembler, some may even use "Absolute" occasionally!

[440bx]

"absolute" is handy to access Windows USER_SHARED_DATA which is always at the same address.

"absolute" is one of FPC's best features.

[silvercoder70]

Or... Absolute(ly)

[marcov]

Real men program in Assembler, some may even use "Absolute" occasionally!

Only in combination with goto's !

[Thaddy]

Real men do not show off their assembler "knowledge", because they know they are outperformed by good high level language compilers.
I make an exception for you, Marco.
I have lost the plot when we needed to take care of cache stalls and the lot...
(that is rather poëtic, lost, plot, lot  )

Back to original question: this is already well explained, it is the memory access and that is intentional.