Hi Przemek,
> > 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. We should IMO never include windows.h from hbdefs.h. Besides slowing down build time to a great deal, we don't do this for other OS APIs either. This would also suggest that Windows API usage is freely allowed in any files, which counteracts with our effort to create portable code in the first place. Most of our core files don't need windows.h. Including windows.h before Harbour header files has the disadvantage that at this point we don't have any standard ways (#ifdef HB_OS_WIN) to detect that we're compiling for Windows. There are of course non-standard ways, but it's quite a big mess, which will probably need hacks on the build side. That kind of sums it up why we have to resort to HB_OS_WIN_USED now. > > +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 ;-) Well, this clearly isn't a search and replace task. It neither is a one pass job, I was rather thinking of laying the grounds for a properly clean type system, at least on paper, as a guideline, and *gradually* shift to use that in practice. Currently there is no Harbour docs about what types to use in what occasions (chars, string types, BYTE* vs. char*, USHORT vs. int in GT, etcetc), and we even have some problems integrating with C code (size_t), plus the potential name collisions, so even our current undocumented system isn't all perfect. Just a simple example to start somewhere: #define HB_INDEX long /* HB_INDEX is used as length and size for Harbour strings and arrays. */ Then start to replace ULONG with HB_INDEX, instead of replacing ULONG with LONG, just so that later we have to identify these again. At a later time, we can make the effort to replace LONGs with HB_INDEX. So why not take this opportunity to solve both problems at the same time? There is common set of source spots that need to be changed for both issues. I think first of all we'd need to design the types we use. > 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. I agree these are very important, but just partially related to my original point. F.e. if we want to fix the unsigned vs. signed issue, why not to introduce a proper and standard type for the entity and start using that? This way we could solve two problems at once. The new type can simply be 'long' either, but in case of indexes, maybe it'd be even better to detach it from C type. ULONG or LONG are both definitly _wrong_ for this purpose though. Maybe I didn't understand well, but are you saying that the raised (name-collision) problem is in your opinion non-existent? The hbfimage build problem on Linux shows the problem quite clearly, and also OW 1.8, however we try to hack it around in Harbour. There is no guarantee that such collision cannot happen anytime in the future with 3rd party packages. What am I missing here? Brgds, Viktor
_______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
