Re: [fpc-devel] possible 'dynlibs' unit issue

2010-01-19 Thread Dariusz Mazur
W dniu 2010-01-19 19:00, Daniël Mantione pisze: 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 wro

Re: [fpc-devel] possible 'dynlibs' unit issue

2010-01-19 Thread Daniël Mantione
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

Re: [fpc-devel] possible 'dynlibs' unit issue

2010-01-19 Thread 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 a

Re: [fpc-devel] possible 'dynlibs' unit issue

2010-01-19 Thread Michael Van Canneyt
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 p

Re: [fpc-devel] possible 'dynlibs' unit issue

2010-01-19 Thread Graeme Geldenhuys
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 - -- fpG

Re: [fpc-devel] possible 'dynlibs' unit issue

2010-01-19 Thread Daniël Mantione
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 oc

Re: [fpc-devel] possible 'dynlibs' unit issue

2010-01-19 Thread 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. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI

Re: [fpc-devel] possible 'dynlibs' unit issue

2010-01-19 Thread Michael Van Canneyt
On Tue, 19 Jan 2010, Graeme Geldenhuys wrote: 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

[fpc-devel] possible 'dynlibs' unit issue

2010-01-19 Thread Graeme Geldenhuys
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. Regar