On Wed, 04 Feb 2009, Szak�ts Viktor wrote: Hi Viktor,
> What would the preferred direction we should go in order > to avoid C type name collisions with external packages, > and OS APIs (like Windows API)? > Here's is an incomplete list of type names which may cause such problems: > BOOL > SCHAR, UCHAR, BYTE > SHORT, USHORT > INT, UINT > LONG, ULONG > INT32, UINT32 > INT64, UINT64 > If cleaned up, we could finally get rid of the HB_OS_WIN_USED > hack and freely include "windows.h" anywhere in C code. It would > allow us to integrate Harbour with any tools without having to > worry about such collisions. > OpenWatcom 1.8 gives hundreds of warnings for INT32. We do not have to use HB_OS_WIN_USED. It's enough to include windows.h before Harbour header files. We can also disable it or include it always in hbdefs.h this is not big problem. We should only add detecting of already included windows.h and clipdefs.h should be fixed a little bit. In practice whole Harbour code can be compiled with windows.h without problems with one exception. bison files and definitions we used for terminal symbols (f.e. IN) which can break also many other things. But this is different problem and now can be easy eliminated. We do not use FLEX so we do not need external header files (harboury.h and macroy.h) and we can simply include compiler (complex.c) and macro (marcolex.c) lexer to grammar files. > 1) One route is to prefix everything with HB_. HB_INT, HB_UINT. > Pretty obvious, but a tad verbose and not very elengant for such > basic types. > 2) Using standard types: int, long, unsigned int. > 3) Combination of the above: standard types for everything > where we can be in sync with underlying compiler types, > and HB_* special types whenever we want to enforce certain > sizes in public Harbour APIs, or to override compiler limits for > consistency, like Harbour string pointer/size, Harbour file pointer > (HB_FOFFSET), Harbour array pointer/size, Harbour character > type (HB_CHAR). One important point is to make above > distinction and planning in advance and in full detail, before > touching the source. > +1) Regardless of the above we should keep legacy types > for Clipper compatibility, so they should be moved to Clipper > compatibility headers. > Any thoughts? This is big and potentially danger modification. Whole code will have to be updated. Even simply copy and replace may create problems and bugs very hard to locate. It will also be problem for 3-rd party developers and existing code. Finally we should not force our own types in functions used as public 3-rd party API because we will only create problems when native OS types have to be translated to Harbour ones. Even know people have serious problems when they have to understand difference between signed and unsigned integer. Such modification will intorduce yet another problem for them with casting between platfom and Harbour types so I do not want to make it. It's not real problem for me now but if we start it then for sure it will ;-) Much important for me is cleaning the code and replacing all BYTE used as synonym of 'unsigned char' with UCHAR and probably fixing the ULONG used as array and string indexes. We should used signed index because many of Clipper/Harbour functions needs negative values so even know it's not true that we can support full ULONG area in all cases (of course it platform has enough space) because such arrays as strings will not be fully functional. I gues that the only one reason why Harbour has ULONG as string and array indexes was caused by the fact that Clipper used USHORT so someone extended it to ULONG without thinking what will happen. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
