[fpc-devel] possible 'dynlibs' unit issue

[Dariusz Mazur]

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