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*()). > > or HB_SIZE if we plan to use it widely as memory block size > holder. Probably we should also create ANSI C compatible > wrappers for malloc()/calloc()/realloc()/free() (BTW we should > also add hb_xgrabz()) which can be used as redirectors in 3-rd > party code. Okay. > It will be also necessary to update all public API functions > which operates on string/array item size or their indexes. > But here we will have problem. In few critical places in core > code we already had to use 'long' instead of 'unsigned long' > when we need negative indexes. If will be bard to touch this > code if HB_SIZE is unsigned and we do not have corresponding > signed type. Yes, I noticed them. We can add 'HB_ISIZ' temporarily to mark these occurrences, where 'HB_ISIZ' is mapped to 'long' and we can swap all 'long' usages to it where used as string/array/hash index / length. At the point when we switch HB_SIZE to 'long', we can simple s&r HB_ISIZ to HB_SIZE, and delete it. >> Plus a few other value types to migrate form ULONG to >> something else: >> >> 32-bit crc values -> HB_U32 > > This is less important, Please only remember that general CRC > functions are using max integers (usually 64bit) and accept such > polynomials. It's only important, because I'd like to get rid of ULONG completely. It's colliding with Windows type with the same name. >> pcount -> int ? > > it's already int. In some places it's ULONG, USHORT, but in this case I'll change it to 'int' where I notice such discrepancy. >> class related ULONG value -> ? > > There is no single replacement for ULONG used in classy code > so it has to be updated manually. OK. >> file attribute -> HB_U32 ? or rather HB_FATTR > > HB_FATTR is OK for me, thank you though please do not forget that > on 64bit platform only in ms-win long is 32bit integer and on all > others it's 64bit so if it's not necessary to use wider type then > internally we can use something mapped to fixed bit sise type. I left it to 'unsigned long', but we can now easily remap it to HB_U32. I'll do this in a next commit. >> arg count -> int ? > > It's not trivial modification it will touch few important internal > structures changing their size and alignment so it will increase > memory usage and may cause some small speed reduction. Now use > [U]SHORT as holders for number of parameters. Since [U]SHORT should also be eliminated, maybe a new special type would be the best here, like HB_PNUM. If I'm not mistaken this is the same entity as mentioned previously in pcount, where it's (or at least should be) int. Probably we should also swicth these occurrences to HB_PNUM (or similar). Your opinion? >> alloc size -> size_t ? > > size_t can be hard to write portable code. Just simply on some > platforms it's signed and on some other unsigned what creates > serious casting problem in portable code. Before we decide to > use it I would like to create table with all supported platforms > /C compilers when we can set it's signed or unsigend type. > BTW such table can be very helpful in the future and can be > extended by other things we wanted to verify, i.e. OS BOOL type > mapping. Okay. I can't contribute here, but it would indeed be useful. Although if size_t is problematic, we are not obliged to mix to Harbour core at all. >> file I/O -> HB_FOFFSET / HB_SIZE > > Yes, > >> clock/time related -> HB_U32 ? > > It will depend on context and precision. HB_U32 is definitely > too small to keep the UTC size in milliseconds like in > hb_dateMilliSeconds(). So maybe a dedicated type would help here, too, like HB_TIME, HB_TIMEMS. >> parinfa retval -> HB_SIZE ? > > It's also used for array size to it has to be HB_SIZE just like > all other functions operating on array/string sizes or indexes. Okay. > and also some types which causes limitations like: > USHORT as number of dynamic symbols. But touching it > will force updating other code, i.e. method hashing algorithm > will have to be replaced be new one. Now it's very fast bust > it needs limited range of symbol numbers, switching to 'int' > will force changing it so this should be done before we touch > it. And this modification also increases memory usage and reduce > a little bit performance. Indeed. I'll leave this for you. I happened to notice a few other types, but after yesterdays modification it's much easier to get an overview about USHORT, ULONG usage by doing simple grep on code. ULONG f.e. is also used as record number and few other things in RDD code. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
