Difference between revisions of "@"
(typo; replace legacy syntaxhighlight syntax; mention loc function of PXSC; unify code style; more specific link target compile-time error) |
|||
| (One intermediate revision by one other user not shown) | |||
| Line 6: | Line 6: | ||
Normally, the value <syntaxhighlight lang="pascal" inline>@</syntaxhighlight> returns is an ''untyped'' [[Pointer|<syntaxhighlight lang="pascal" inline>pointer</syntaxhighlight>]]. | Normally, the value <syntaxhighlight lang="pascal" inline>@</syntaxhighlight> returns is an ''untyped'' [[Pointer|<syntaxhighlight lang="pascal" inline>pointer</syntaxhighlight>]]. | ||
| − | If you are handling pointers a lot, and want to mitigate issues with passing references of wrong type’s target, you have use the [[Compiler directive|directive]] [[$typedAddress|<syntaxhighlight lang="pascal" inline>{$ | + | If you are handling pointers a lot, and want to mitigate issues with passing references of wrong type’s target, you have use the [[Compiler directive|directive]] [[$typedAddress|<syntaxhighlight lang="pascal" inline>{$typedAddress on}</syntaxhighlight>]]. |
Here is an example to demonstrate what produces with untyped pointers valid and functional code, but semantically outputs an erroneous result: | Here is an example to demonstrate what produces with untyped pointers valid and functional code, but semantically outputs an erroneous result: | ||
| Line 29: | Line 29: | ||
== other remarks == | == other remarks == | ||
* In [[ASCII]] the character <syntaxhighlight lang="pascal" inline>@</syntaxhighlight> (AT sign): has the value <syntaxhighlight lang="pascal" inline>64</syntaxhighlight>. | * In [[ASCII]] the character <syntaxhighlight lang="pascal" inline>@</syntaxhighlight> (AT sign): has the value <syntaxhighlight lang="pascal" inline>64</syntaxhighlight>. | ||
| − | * | + | * [[PXSC]] defines the <syntaxhighlight lang="pascal" inline>loc</syntaxhighlight> function as the address-operator. |
== read more == | == read more == | ||
| − | * [https://www.freepascal.org/docs-html/ref/ | + | * [https://www.freepascal.org/docs-html/ref/refse87.html The <syntaxhighlight lang="pascal" inline>@</syntaxhighlight> operator] |
* [https://www.freepascal.org/docs-html/prog/progsu75.html Typed address operator (<syntaxhighlight lang="pascal" inline>@</syntaxhighlight>)] | * [https://www.freepascal.org/docs-html/prog/progsu75.html Typed address operator (<syntaxhighlight lang="pascal" inline>@</syntaxhighlight>)] | ||
* [[Addr|<syntaxhighlight lang="pascal" inline>addr</syntaxhighlight>]] | * [[Addr|<syntaxhighlight lang="pascal" inline>addr</syntaxhighlight>]] | ||
{{Symbols}} | {{Symbols}} | ||
Latest revision as of 08:04, 28 February 2024
│
English (en) │
suomi (fi) │
français (fr) │
русский (ru) │
The address operator @ returns the address of an identifier that is associated with an address (usually a variable or routine, but also a label).
Normally, the value @ returns is an untyped pointer.
If you are handling pointers a lot, and want to mitigate issues with passing references of wrong type’s target, you have use the directive {$typedAddress on}.
Here is an example to demonstrate what produces with untyped pointers valid and functional code, but semantically outputs an erroneous result:
1program untypedAddressDemo(input, output, stderr);
2
3procedure incrementIntByRef(const ref: PByte);
4begin
5 inc(ref^);
6end;
7
8var
9 foo: integer;
10begin
11 foo := -1;
12 incrementIntByRef(@foo);
13 writeLn(foo);
14end.
It was intended that 0 (zero) gets printed, but the program prints -256 instead.
With {$typedAddress on} compilation fails with an incompatible type error.
You usually want the latter behavior (compile-time error) instead of wasting time with hours of debugging.
other remarks
- In ASCII the character
@(AT sign): has the value64. - PXSC defines the
locfunction as the address-operator.
read more
| single characters |
|
| character pairs |
|
