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
