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. 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. 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. > 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. > pcount -> int ? it's already int. > class related ULONG value -> ? There is no single replacement for ULONG used in classy code so it has to be updated manually. > 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. > 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. > 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. > 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(). > 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. 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. best regards, Przemek _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
