Hi Przemek,
> Now if possible and necessary then please update hbprintf.c for
> MSVC. It's the last popular compiler I haven't tested. We should
I've made and attempt, but it turned out Microsoft refuses to
support C99 standard (they push ppl to use recent C++ standards
instead). They don't sup
Hi Phil,
> Again, our other, much simpler and consistent option is to simply swap the
>> manual mails to automated ones, with no change on any parties side.
>>
> Ok, that was a very coherent discussion that adds meaning that you were not
> conveying before. Thank you.
>
> Earlier, it was requeste
MSVC 8.0 gives these errors:
source\common\hbprintf.c(316) : error C2061: syntax error : identifier
'intmax_t'
source\common\hbprintf.c(317) : error C2061: syntax error : identifier
'as_x_uintmax_t'
source\common\hbprintf.c(317) : error C2059: syntax error : ';'
source\common\hbprintf.c(325) : erro
On Wed, 28 Jan 2009, Szak�ts Viktor wrote:
Hi Viktor,
> MSVC 8.0 gives these errors:
> source\common\hbprintf.c(316) : error C2061: syntax error : identifier
> 'intmax_t'
[...]
Look at hbprintf.c source and add prober MSVC #define in places marked
as TODO.
Probably updating the 1-st one which de
2009-01-28 13:29 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/source/common/hbprintf.c
* redefine [u]intmax_t as [U]LONGLONG in MSVC builds.
best regards
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.ha
Thanks a lot.
Now, these are the only warnings remaining:
source\common\hbprintf.c(1036) : warning C4013: '_finite' undefined;
assuming extern returning int
c:\work\harbour-new\harbour\source\common\hbprintf.c(1191) : warning C4701:
potentially uninitialized local variable 'size' used
Brgds,
Vikto
Przemek,
The return value does not include the terminating null byte in the count.
...
if( c != 0 ) ++size;
}
while( c != 0 );
...
I made a few tests with BCC and Spd add #define snprintf hb_snprintf_c
and the basics are working but with differences in accuracy.
? S
On Wed, 28 Jan 2009, Szak�ts Viktor wrote:
> Thanks a lot.
> Now, these are the only warnings remaining:
> source\common\hbprintf.c(1036) : warning C4013: '_finite' undefined;
> assuming extern returning int
In 99% this function have to be defined in float.h it's so it should
be enough to include
2009-01-28 14:25 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/source/common/hbprintf.c
! include float.h in MSVC builds
* changed code a little bit to pacify MSVC warning
best regards
Przemek
___
Harbour mailing list
Harbour@h
Hi Przemek,
> > Now, these are the only warnings remaining:
> > source\common\hbprintf.c(1036) : warning C4013: '_finite' undefined;
> > assuming extern returning int
>
> In 99% this function have to be defined in float.h it's so it should
> be enough to include this file.
> I'll commit modificat
Many thanks. Getting better, now this one remains:
source\common\hbprintf.c(1035) : warning C4244: 'function' : conversion from
'long double' to 'double', possible loss of data
I've checked line 1035, but I'd rather not touch it.
Brgds,Viktor
On Wed, Jan 28, 2009 at 2:25 PM, Przemyslaw Czerpak
Hi,
Compiling test attached compiler Harbour.exe GPFs.
Command line:
d:\harbour\bin\harbour test -n -p -id:\harbour\include
Compiler options seems significant.
Harbour 1.1.0dev (Rev. 10127)
WinXP, BCC5.8
Best regards,
Saulius
test.tar.gz
Description: GNU Zip compressed data
On Wed, 28 Jan 2009, Xavi wrote:
Hi Xavi,
> The return value does not include the terminating null byte in the count.
> ...
> if( c != 0 ) ++size;
> }
> while( c != 0 );
> ...
I cannot find such code in hbprintf.c.
hb_printf_c() for sure sets trailing \0 byte in all cases ev
On Wed, 28 Jan 2009, Szak�ts Viktor wrote:
Hi,
> source\common\hbprintf.c(1035) : warning C4244: 'function' : conversion from
> 'long double' to 'double', possible loss of data
> I've checked line 1035, but I'd rather not touch it.
Please check if MSVC has _finite() function which can accept
'lo
2009-01-28 17:41 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/source/common/hbprintf.c
! do not use _fpclass() in BCC builds - it breaks FL arithmetic
* use _finitel() instead of _finite() in MSVC builds
best regards
Przemek
_
Hi Przemek,
I've found these in float.h: (no long double finite, but there's
an isnan, plus fpclass() with some useful stuff)
---
#ifndef _SIGN_DEFINED
_CRTIMP __checkReturn double __cdecl _copysign (__in double _Number, __in
double _Sign);
_CRTIMP __checkReturn double __cdecl _chgsign (__in doubl
Intresting comparison harbour & xharbour by activity
http://www.ohloh.net/p/compare?metric=Activity&project_0=harbour+project&project_1=xHarbour+Extended+Harbour+Compiler
--
Massimo Belgrano
___
Harbour mailing list
Harbour@harbour-project.org
http://l
2009-01-28 19:03 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/source/common/hbprintf.c
* disabled _finitel() in MSVC builds, added casting to double instead
best regards
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
Przemek,
I cannot find such code in hbprintf.c.
In the line 1181: ++size;
Sorry, I needed added for testing the if( c != 0 ) and I thought that you would
see more clearly.
hb_printf_c() for sure sets trailing \0 byte in all cases even if buffer
is too small.
Yes, but return size accumulate
On Wed, 28 Jan 2009, Xavi wrote:
Hi Xavi,
>> I cannot find such code in hbprintf.c.
> In the line 1181: ++size;
> Sorry, I needed added for testing the if( c != 0 ) and
> I thought that you would see more clearly.
Sorry, it confused me.
>> hb_printf_c() for sure sets trailing \0 byte in all cas
Przemek,
Yes you're right. But sorry for my bad English.
http://www.opengroup.org/onlinepubs/009695399/functions/fprintf.html
"Return value: Upon successful completion, the snprintf() function shall return the number of bytes that would be written to s
had n been sufficiently large *excluding t
On Wed, 28 Jan 2009, Xavi wrote:
Hi Xavi,
> Yes you're right. But sorry for my bad English.
Not worse then mine.
Now I understand that you are talking about integer value returned
by snprintf() not about the buffer contents. Sorry my fault.
> http://www.opengroup.org/onlinepubs/009695399/functi
Hi Przemek,
Ok, Thanks to you and sorry for my bad English.
Best regards,
Xavi
Przemyslaw Czerpak escribió:
On Wed, 28 Jan 2009, Xavi wrote:
Hi Xavi,
Yes you're right. But sorry for my bad English.
Not worse then mine.
Now I understand that you are talking about integer value retu
2009-01-28 22:28 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/source/vm/itemapi.c
% eliminated hb_snpritf() from HB_IT_POINTER conversion in
hb_itemString()
* harbour/source/common/hbprintf.c
! fixed return value - it should be one less. Thanks to Xavi.
+ ad
Hi Przemek,
Il 28/01/2009 3.52, Przemyslaw Czerpak ha scritto:
First of all thank you for your detailed explanation,
[snip]
HB_REINIT_STATIC
HB_KEEP_LOCAL_REFERENCES
good
HB_OVERLOAD_FUNCTIONS
interesting, but, as you pointed out, is dangerous in code like HTTP
server, so my v
Hi,
my friends showed a few more Clipper incompatibilites.
1) negative julian dates
SET(4, "-mm-dd")
dDate := CTOD("") - 1
? dDate // Clipper: "1449-02-15", Harbour: "- - "
I would suggest to fix a code for samples like this, but sometimes this
Harbour behaviour can lead to
>
> I've just check BCC5.5 and it's even worse. BCC *ignores* buffer size
> in [v]snprintf() functions so there is not protection at all. It means
> that also our hb_snprintf() which uses internally vsnprintf() does
> not give any protection. It's _VERY_ serious bug and it means that
> at least for
On Thu, 29 Jan 2009, Mindaugas Kavaliauskas wrote:
Hi,
> my friends showed a few more Clipper incompatibilites.
> 1) negative julian dates
> SET(4, "-mm-dd")
> dDate := CTOD("") - 1
> ? dDate // Clipper: "1449-02-15", Harbour: "- - "
> I would suggest to fix a code for samples
2009-01-29 02:16 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/source/common/hbprintf.c
* minor modification for easier future updating
* harbour/source/rdd/dbfntx/dbfntx1.c
! fixed possible GPF caused by corrupted indexes
* harbour/source/rdd/dbfcdx/dbfcdx1.c
!
Hi,
Index is not created due to invalid index key expression: ""
Current DBFCDX detects it and do not create index but RT
error is not generated. Clipper does not validate key expression.
I do not remember why exactly we added stringed key expression
validation but it was done in last few months
On Wed, 28 Jan 2009, Francesco Saverio Giudice wrote:
Hi,
> Just 3 other questions:
> 1 - I would like to limit use of some functions that may be dangerous if
> used from a user, like zap a database or FErase, but this are only two
> samples and maybe not pertinent in real developing, or to oth
Hi,
1) negative julian dates
SET(4, "-mm-dd")
dDate := CTOD("") - 1
? dDate // Clipper: "1449-02-15", Harbour: "- - "
...
So at beginning we should not expect that the date converted to
string should will be non empty if date is not empty. It isn't
even with Clipper.
? ct
32 matches
Mail list logo
