Re: [Harbour] Cleaning Harbour C types

2009-03-26 Thread Viktor Szakáts
Hi Przemek, I see your point and I agree with HB_PATH_MAX, and making sure it's always sized properly for all platforms. But: doing so without including windows.h in all files. One other solution is to add a Harbour API to retrieve this value, or even to allocate a filename buffer at once. Both n

Re: [Harbour] Cleaning Harbour C types

2009-03-26 Thread Przemyslaw Czerpak
On Fri, 06 Feb 2009, Przemyslaw Czerpak wrote: Hi, > > 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

Re: [Harbour] Cleaning Harbour C types

2009-02-06 Thread Viktor Szakáts
Hi Przemek, Generically speaking IMO it's the wrong solution for avoiding bugs to uniformly require the addition of all full OS headers to each source files, if that's what you say. Be those OS headers windows.h files or any other OS files. [ If that's what you're suggesting that is, your words ar

Re: [Harbour] Cleaning Harbour C types

2009-02-06 Thread Przemyslaw Czerpak
On Thu, 05 Feb 2009, Szak�ts Viktor wrote: Hi Viktor, > 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 count

Re: [Harbour] Cleaning Harbour C types

2009-02-05 Thread Viktor Szakáts
Yes, it's inside one of my entries in ChangeLog as TOFIX. I didn't want to touch that, but already searched for toupper/tolower/islower/etc references, and there isn't a great number of them fortunately. I've also added Harbour API replacement for these. Some of them currently using above function

Re: [Harbour] Cleaning Harbour C types

2009-02-05 Thread Przemyslaw Czerpak
On Thu, 05 Feb 2009, Przemyslaw Czerpak wrote: [...] Hi, And one thing else much more important for me because it's a real problem in current code which may cause unpredictable results, f.e. some index corruption. We should eliminate functions which uses locale settings because they can badly chan

Re: [Harbour] Cleaning Harbour C types

2009-02-05 Thread Viktor Szakáts
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 alrea

Re: [Harbour] Cleaning Harbour C types

2009-02-05 Thread Przemyslaw Czerpak
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,

Re: [Harbour] Cleaning Harbour C types

2009-02-04 Thread Viktor Szakáts
ore, as in _i1 (16bit in 16 bit OS; 32bit in 32 bit OS); just my 2 > cents ;-) > > frank > > - Original Message - > > *From:* Viktor Szakáts > *To:* Harbour Project Main Developer List. > *Sent:* Wednesday, February 04, 2009 1:45 AM > *Subject:* [Harbour] Clean

Re: [Harbour] Cleaning Harbour C types

2009-02-04 Thread frank van nuffel
AM Subject: [Harbour] Cleaning Harbour C types Hi all, 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:

[Harbour] Cleaning Harbour C types

2009-02-03 Thread Viktor Szakáts
Hi all, 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, UINT