Hi,

In the file rtl/unix/dynlibs.inc there is the following definition. ----------------
Type
{ using PtrInt here is compliant with the other platforms }

  TLibHandle = PtrInt;

--------------------

Shouldn't that rather be PtrUInt type? After all, PtrUInt was recommended on the wiki.

Regards,
- Graeme -

Why should it be better ? It doesn't really matter anyway. Anyone relying on the actual type is doing something wrong in each case.

Michael.

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.

Regards,
- Graeme -

Op Tue, 19 Jan 2010, schreef Graeme Geldenhuys:

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?

Daniël

Daniël Mantione wrote

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?

OK, now it makes sense. Thanks for the clear explanation.

Regards,
- Graeme -

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.

Michael.

W dniu 2010-01-19 13:53, Michael Van Canneyt pisze:

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?

Op Tue, 19 Jan 2010, schreef Dariusz Mazur:

Is this possible to forbid this at compile time?

An easy solution is to wrap it inside a record. This is good practise as it prevents accidental bugs like accidentally writing parameters in the wrong order when calling a procedure. It's basically the point of type safety.

Some languages have "opaque" types designed for this purpose, the difference being that a record only protects against accidental calculations (you could modify the field in the record), while an actual opaque type could enforce it.

Daniël

W dniu 2010-01-19 19:00, Daniël Mantione pisze:

Yes. I use this very often. But it is possible only for new types. When we want to test or protect some sort of operation on huge source its harder. Operator overloading is enough but lack something that detect invoke of this function. And its not only for this solution, appliance is much wider (f.e. generics)