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
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,
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
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
!
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
>
> 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
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
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
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,
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
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
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,
>> 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,
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
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
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
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
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
_
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
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
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
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 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
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
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
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
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
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
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
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
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
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
32 matches
Mail list logo
