>> 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. > 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. Yes, I know. Next step will be tougher, when we switch HB_SIZE to signed size and we fix all these problems. > 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. Nevertheless it should be done, most probably in several iterations, until all such places are found. If we can locate the typical cases, I think it can be done. Similar to 'const char *' conversion. > 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. Yes, this is again a task to make at the time when we will redefine the type. In first pass, everyone should keep handling it as before. Of course the final goal is to change the type, so what you say should be done. Here one basic question is whether we want to offer a consistent range regardless of platform/architecture, or we tie it a C type, like int or size_t. Since we're first and foremost a Clipper compatible high level compiler, probably the former should be done, but in this case we also limit Harbour programs when backend changes to 128 bit in the future (or to 64-bit already). We may also guarantee a minimum range, 32-bit signed, and say that 64-bit and 128-bit systems automatically allow more. But this may raise some interoperability problems, question is how grave these are. With the advent of 64-bit systems, it may be a reasonable feature for Harbour apps to hold even several GBs of data in one string, so it's not an easy decision. >> 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; For sure. I used to do this when I find such code, but it's not complete and need more code review. But the end result will be cleaner. Also C++ bool and HB_BOOL conversions need to be handled. There is even pending OS/2 problem in HBQT related to this. > 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. Yes, well said. On Windows it's declared 'long'. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
