On Mon, 08 Feb 2010, Szak�ts Viktor wrote: Hi Viktor,
> There is the known problem of HB_LONG, HB_ULONG > which should be the Harbour type name for former > LONG / ULONG types, but in the past it has been > used to denote largest integer type on given > platform. To be more precise. HB_LONG was used for HB_IT_LONG type. It's not largest integer on given platform but it's largest integer item used by HVM. > Now its superseded by HB_MAXINT, HB_MAXUINT, and > Harbour codebase has been changed to use it. It should be rather HB_VM[U]LONG or HB_VMMAX[U]INT though the exact meaning depends on context. In few places it should be HB_MAX[U]INT so it cannot be done by global S&R. Now it's not critical but when compilers using wider then 64bit integers will appear we will have to clean it. It's also possible to compile Harbour with strict Clipper HB_IT_INTEGER and HB_IT_LONG mapping and it also exploits the problem. It should be fixed in hbdefs.h and I'll make it soon so it's not a problem. > This means no Harbour code use HB_LONG and > HB_ULONG anymore. Thank you very much for your modifications. > I believe this type was not overused in > 3rd party code (I could only find a few placed > in LetoDB where it's used), so it's not big job to > update them where needed, and even by staying > compatible with older Harbour and even xhb version > (simply by creating new type HB_MAXINT/HB_MAXUINT). Yes, it is. In current LETO code HB_ULONG is used only for hb_dateMilliSec() but later casted to 'long' so in all windows builds and other 32bit build it's already stripped to 32bit integer. HB_LONG is used in context where it can be replaced by HB_MAXINT. > If we go this route, we may reuse HB_LONG and > HB_ULONG as replacements for LONG / ULONG. So > this would be a small breakage of compatibility, > but would give us clean and clear type naming > system. I'd vote to do this. For me it's very good choice. In the moment when we decided to add new types with 'HB_' prefix instead of using 'hb' (i.e. hbLong, hbInt, ... ) then we created potential conflicts with existing types using HB_ prefix like HB_LONG or HB_PCODE and we have to clean them. My opinion is that we should not leave any old types which may confuse users. Last modifications force code updating so let's change HB_[U]LONG too. IMO the worse situation is when such modificaitons tooks too much time and 3-rd party developers have to systematically update his code. Anyhow here we should clearly announce that: HB_[U]LONG _STOPS_ TO BE 64 BIT INTEGER. NOW IT'S 32 BIT INTEGER. because in this particular case the modification does not cause compile time errors. best regards, Przemek _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
