[fpc-pascal] Re: Assigning pointer address

dhkblaszyk at zeelandnet.nl dhkblaszyk at zeelandnet.nl
Mon Oct 1 14:18:13 CEST 2012


On 1 okt '12, Reinier Olislagers wrote: 

> On 1-10-2012 13:55,
dhkblaszyk-47ckw973qWsGTViba+RHyw at public.gmane.org [4]wrote:
>> On 1
okt '12, michael.vancanneyt-0Is9KJ9Sb0A at public.gmane.org [3]wrote: 

>>> On Mon, 1 Oct 2012, dhkblaszyk at zeelandnet.nl
[2]dhkblaszyk-47ckw973qWsGTViba+RHyw at public.gmane.org>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
>> 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
> 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
> _______________________________________________
fpc-pascal maillist - fpc-pascal at lists.freepascal.org [5]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal [6]

Nah, I
wasn't thinking about letting fpdoc predict anything. Instead though it
would be nice to introduce something that helps the documenter flag a
certain piece of code and let fpdoc know that it should show
alternatives or instead a separate piece of code (similar as examples



mailto:dhkblaszyk at zeelandnet.nl
mailto:michael.vancanneyt-0Is9KJ9Sb0A at public.gmane.org
mailto:dhkblaszyk-47ckw973qWsGTViba+RHyw at public.gmane.org
mailto:fpc-pascal at lists.freepascal.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20121001/144ae9cb/attachment.html>

More information about the fpc-pascal mailing list