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: > 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 like using > negative indexes in some RTL functions but it will be necessary > to update probably a lot of code to resolve signed<->unsigned > conversion problems. BTW in practice we do not fully support > unsigned indexes in the whole range now so switching to signed > values is not reduction but rather cleaning code to eliminate > unexpected bad side effect which can appear for very big indexes. > > In last year many size castings have been added to pacify > size conversion warnings. Now such castings will pacify also > important warnings in code which should be updated if we > decide to extend HB_SIZE i.e. to LONGLONG in Win64 builds > so it may not be easy job to locate all such places. > > Finally we should clearly define the HB_SIZE range to not confuse > users writing C code. Now we use ULONG so everyone knows what this > type and how to make conversions between ULONG and native OS types. > When we introduce HB_SIZE then programmers will need precise > information about this type and what native OS type can be used > to hold such values. > >> 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. > > Yes, though maybe we should define rules for conversion between > HB_BOOL and BOOL. So far MS-Win users used the same type as in > Harbour sometimes even directly. Now they will have to know if > it's legal to make: > hbBoolValue1 = BoolValue1; > BoolValue2 = hbBoolValue2; > or it's necessary to make: > hbBoolValue = BoolValue != 0; > or: > hbBoolValue = BoolValue ? HB_TRUE : HB_FALSE; > In most of cases BOOL is defined as 'int' though on some platforms > it may be sth different, i.e. BYTE or SHORT. > Here we can resolve the problem declaring that HB_BOOL will be > always 'int' in all platforms and it does not depend on any native > BOOL type but it's necessary to check how exactly it was defined on > all platforms using HB_DONT_DEFINE_BASIC_TYPES to know what will > change and correctly define translation rules between HB_BOOL and > BOOL. > > best regards, > Przemek > _______________________________________________ > Harbour mailing list (attachment size limit: 40KB) > [email protected] > http://lists.harbour-project.org/mailman/listinfo/harbour _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
