[fpc-devel] possible 'dynlibs' unit issue

Dariusz Mazur darekm at emadar.com
Tue Jan 19 18:53:00 CET 2010

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;
   abstract;  //compiler can give error at place of invoke

is this possible?


More information about the fpc-devel mailing list