Hi,

I want to ask if casting an integer to a pointer is valid over all platforms. See below:

p: PInteger;
v: longint;

[...]

v :=
4235423;
p := PInteger(v);

Of course, the value of the pointer
adress may vary, but in general is this a valid way to assign a pointer? Or will some platforms or architecture give problems?

Darius

On Mon, October 1, 2012 10:43, wrote:

Hi,

Use PtrInt (signed) or PtrUInt (unsigned) types instead of longint, etc. The former two are guaranteed to work for all architectures and platforms. Your particular example fails on all 64-bit architectures (among others) immediately.

Tomas

Hi Tomas,

Thanks for clarifying. I will use PtrUInt to store the pointer address in. BTW: the documentation it says not to use PtrInt because it's signed and therefore smaller than a pointer (as in max value).

Also there seems to be an error in the documentation. On http://www.freepascal.org/docs-html/rtl/system/ptruint.html [4] it is described that PtrUInt is an alias to DWord. However, it depends on the architecture which type it actually is. Could someone please correct the docs?

TIA

Regards, Darius

Tomas Hajny wrote

On

[1] wrote

Hi,

> I want to ask if casting an integer to a pointer is valid over

all platforms. See below: p: PInteger; v: longint; [...] v := 4235423; p
:= PInteger(v); Of course, the value of the pointer adress may vary, but
in general is this a valid way to assign a pointer? Or will some
platforms or architecture give problems?

Use PtrInt (signed) or

PtrUInt (unsigned) types instead of longint, etc.

The former two are

guaranteed to work for all architectures and platforms.

Your

particular example fails on all 64-bit architectures (among others)

immediately.

Tomas

What do you want to see corrected ?

On 32-bit systems, it is a DWord. The docs were generated on such a system, so you get this definition.

Michael.

On Mon, 1 Oct

[2] wrote

> Hi Tomas, Thanks for

clarifying. I will use PtrUInt to store the pointer address in. BTW: the documentation it says not to use PtrInt because it's signed and therefore smaller than a pointer (as in max value). Also there seems to be an error in the documentation. On
http://www.freepascal.org/docs-html/rtl/system/ptruint.html [1] [4] it is described that PtrUInt is an alias to DWord. However, it depends on the architecture which type it actually is. Could someone please correct the docs?

What do you want to see corrected ? On 32-bit

systems, it is a DWord. The docs were generated on such a system,

so

you get this definition.

Michael.

That sounds good (vaguely remember that PtrUint also depends on OS, but leaving it to more knowledgeable people to updat the docs anyway)

In the ideal case fpdoc should be adjusted so it can handle these defines. However this will be very complex I assume.

IIUC, size PtrUint varies by architecture, which is more or less the point of PtrUint.
Having this variation documented as Darius suggested above makes things much clearer, because the programmer may be working on one platform and programming for another (with {$IFDEFS}...).

Letting fpdoc predict this seems like a way to madness.

Yes and no.

You're supposed to treat this as an opaque type, i.e. all you're supposed to know is that it is:
1) An integer type (signed or not).
2) Same size as a pointer type on all platforms.

If we start specifying when it is of what type, then a) we need to maintain this.
b) people will start making assumptions.

We exactly need to avoid b)

Michael.

Reinier Olislagers wrote

On 1-10-2012 13:55,

[4] wrote

> On 1

Hi Tomas, Thanks for clarifying. I will use PtrUInt to store the pointer address in. BTW: the documentation it says not to use PtrInt because it's signed and therefore smaller than a pointer (as in max value). Also there seems to be an error in the documentation. On http://www.freepascal.org/docs-html/rtl/system/ptruint.html [1] [4] it is described that PtrUInt is an alias to DWord. However, it depends on the architecture which type it actually is. Could someone please correct the docs?

>> What do you want to see corrected ? On 32-bit systems, it

is a DWord. The docs were generated on such a system, so you get this definition.

> If possible I would like to see a remark mentioning that

it's a QWord on 64bit and Word on 16bit. That by itself would make thing clearer already.

That sounds good (vaguely remember that PtrUint

also depends on OS, but

leaving it to more knowledgeable people to

updat the docs anyway)

> In the ideal case fpdoc should be adjusted

so it can handle these defines. However this will be very complex I assume.

IIUC, size PtrUint varies by architecture, which is more or

less the

point of PtrUint. Having this variation documented as

Darius suggested above makes things

much clearer, because the

programmer may be working on one platform and

programming for another

(with {$IFDEFS}...).

Letting fpdoc predict this seems like a way to

madness.

_______________________________________________

Since fpdoc relies on a pascal parser that only accepts valid pascal code, such a mechanism seems very unlikely to me.

Michael.

You're obviously right, but since we include documentation built on a 32-bit architecture as a universal one for all releases/architectures and since it currently explicitly includes information that 'PtrUInt = DWord', we should either make sure that this equation doesn't appear in the documentation (which may be difficult considering how the docs are created), or (more likely) provide additional information which allows the reader to interpret the statement correctly. Choosing the right wording (to stress the opaque nature of this type) is obviously up to you, but a request for some kind of clarification added to the docs is IMHO absolutely reasonable.

Tomas

Absolutely, and I plan to do so :-)

Michael.