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
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
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
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
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
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
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
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,
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
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:
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
11 matches
Mail list logo