Re: [Harbour] ULONG -> HB_SIZE

2010-01-15 Thread Viktor Szakáts
Hi Przemek, On 2010 Jan 15, at 09:39, Przemysław Czerpak wrote: > On Thu, 14 Jan 2010, Szak�ts Viktor wrote: >> The other area which will need to be cleaned is >> mem allocation functions (as discussed before). >> Currently it uses ULONG, but should be size_t probably. >> (GC and hb_x*()). > >

Re: [Harbour] ULONG -> HB_SIZE

2010-01-15 Thread Przemysław Czerpak
On Thu, 14 Jan 2010, Szak�ts Viktor wrote: Hi, > The other area which will need to be cleaned is > mem allocation functions (as discussed before). > Currently it uses ULONG, but should be size_t probably. > (GC and hb_x*()). or HB_SIZE if we plan to use it widely as memory block size holder. P

Re: [Harbour] ULONG -> HB_SIZE

2010-01-14 Thread Viktor Szakáts
Hi Przemek, The other area which will need to be cleaned is mem allocation functions (as discussed before). Currently it uses ULONG, but should be size_t probably. (GC and hb_x*()). Plus a few other value types to migrate form ULONG to something else: 32-bit crc values -> HB_U32 pcount -> int

Re: [Harbour] ULONG -> HB_SIZE

2010-01-14 Thread Viktor Szakáts
> On Thu, 14 Jan 2010, Szak�ts Viktor wrote: First actual question is what to do with ULONG in hb_fsSeek(). Should it be changed to HB_SIZE or not? >>> No. It cannot be HB_SIZE. It will be bug. The same is for other >>> functions like hb_fsWriteLarge(). All such functions have to use >>>

Re: [Harbour] ULONG -> HB_SIZE

2010-01-14 Thread Przemysław Czerpak
On Thu, 14 Jan 2010, Szak�ts Viktor wrote: > >> First actual question is what to do with ULONG in > >> hb_fsSeek(). Should it be changed to HB_SIZE or not? > > No. It cannot be HB_SIZE. It will be bug. The same is for other > > functions like hb_fsWriteLarge(). All such functions have to use > > p

Re: [Harbour] ULONG -> HB_SIZE

2010-01-14 Thread Viktor Szakáts
Hi, >> First actual question is what to do with ULONG in >> hb_fsSeek(). Should it be changed to HB_SIZE or not? > > No. It cannot be HB_SIZE. It will be bug. The same is for other > functions like hb_fsWriteLarge(). All such functions have to use > parameters which are accepted by low level OS

Re: [Harbour] ULONG -> HB_SIZE

2010-01-14 Thread Przemysław Czerpak
On Thu, 14 Jan 2010, Szak�ts Viktor wrote: Hi, > First actual question is what to do with ULONG in > hb_fsSeek(). Should it be changed to HB_SIZE or not? No. It cannot be HB_SIZE. It will be bug. The same is for other functions like hb_fsWriteLarge(). All such functions have to use parameters w

Re: [Harbour] ULONG -> HB_SIZE

2010-01-13 Thread Viktor Szakáts
Hi Przemek, First actual question is what to do with ULONG in hb_fsSeek(). Should it be changed to HB_SIZE or not? [ On the longer run it will need to be changed to non-Windows type anyway, so we can decide about it even now. ] Brgds, Viktor On 2010 Jan 14, at 02:44, Przemysław Czerpak wrote

Re: [Harbour] ULONG -> HB_SIZE

2010-01-13 Thread Viktor Szakáts
>> Any objection to start migrating all ULONG types which is >> used as string/array length, position to convert to HB_SIZE >> in all Harbour source code? > > What C type you plan to use for HB_SIZE? I didn't plan to make any changes in this round of modification, so it'd stay as ULONG. > Usi

Re: [Harbour] ULONG -> HB_SIZE

2010-01-13 Thread Przemysław Czerpak
On Thu, 14 Jan 2010, Szak�ts Viktor wrote: Hi, > Any objection to start migrating all ULONG types which is > used as string/array length, position to convert to HB_SIZE > in all Harbour source code? What C type you plan to use for HB_SIZE? Using signed type resolves many problems we have now l

[Harbour] ULONG -> HB_SIZE

2010-01-13 Thread Viktor Szakáts
Hi All, Any objection to start migrating all ULONG types which is used as string/array length, position to convert to HB_SIZE in all Harbour source code? At the same time I'd like to also convert all BOOL/TRUE/FALSE to HB_BOOL/HB_TRUE/HB_FALSE. This is fully mechanical process. Brgds, Viktor