W dniu 2010-01-19 13:53, Michael Van Canneyt pisze:
On Tue, 19 Jan 2010, Daniël Mantione wrote:
Op Tue, 19 Jan 2010, schreef Graeme Geldenhuys:
Michael Van Canneyt wrote:
Why should it be better ? It doesn't really matter anyway.
PtrUInt has a larger range than PtrInt (allowing full access to memory
address range). Plus, I don't think pointers can be negative values.
The problem occurs when doing pointer arithmetic "ptrint+integer" is
a bug, because it will overflow if the original pointer<$8000000 and
the result pointer>=$8000000. It is especially dangerous in loops like:
q:=p+distance;
while p<q do
begin
{...}
inc(p);
end;
I don't want to think how many bugs have been coded this way :)
However, when using pointers as handles it is another matter...
Handles are not to be used in any calculation, so they cannot
overflow. Who cares if you get a negative handle?
That is what I meant. The TLibhandle type is opaque. You're not
supposed to
know that it is a pointer, integer or whatnot. And definitely you
should not
do math on them.
Is this possible to forbid this at compile time?
I thinking about something like this:
operator + (a : tLibHandle; b: integer) res : tLibHandle;
begin
abstract; //compiler can give error at place of invoke
end;
is this possible?
--
Darek
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
