On Sun, 09 Mar 2008, Massimo Belgrano wrote:
> I have executed hbtest of harbour and I receive 22 error
> What result must I receive
> I have missed something?
The results shows some of differences between Harbour and Clipper.
> ! 724 MAIN_HVMA(503) RTSTR( 00000500000000000000 )
> Result: " 16 500000000000000"
> Expected: " 21 500000000000000"
> ! 725 MAIN_HVMA(504) RTSTR( 0500000000000000 )
> Result: " 16 500000000000000"
> Expected: " 17 500000000000000"
Harbour supports 64 bit integer numbers so some rules which are used
in Clipper for integer numbers works in Harbour for much bigger numbers
then in Clipper. In generated PCODE all integer numbers are stored
without information about the size used for string formatting. Such
information is only with PCODE used for DOUBLE values. This is Clipper
compatible behavior fully replicated in Harbour. But because Harbour
supports 64bit signed integers then this rule is used for bigger range
of numbers. The difference can be seen in code which uses integer
numbers with 0 prefix which are over the range -2^31 : 2^31-1 but
inside 2^63-1 : 2^63, f.e.:
? 00100000000000
If you needs strict Clipper compatible results then you uncomment
this line:
/* #define PCODE_LONG_LIM(l) HB_LIM_INT32( l ) */
in include hbdefs.h
We can also hide this incompatibility by intorducing new PCODE for
64bit signed integers which will keep also the default string formatting
size but I do not know if such minor difference is enough to introduce
new PCODE. Anyhow hbtest nicely show it.
> ! 1069 MAIN_MATH(359) Str(1234567890 * 1234567890 )
> Result: " 1524157875019052100"
> Expected: " 1524157875019052000"
This is also side effect of 64 bit integer support. Just simply 64 bit
integer es have smaller range then IEEE754 double values but bigger
precision. IEEE754 double value has 53 bit precision and 64 bit integers
63bit. When Clipper converts double values to string then only 15 most
significant decimal digits are presented and rest is 0. Harbour stores
the results in 640bit integer and presents exact value: 1524157875019052100
Here also hbtest shows the difference between Harbour and Clipper and
this difference can also be hidden very easy in hbdefs.h if you really
need strict compatibility.
> ! 3198 MAIN_MISC(554) HB_SToD("99990101")
> Result: HB_SToD("99990101")
> Expected: HB_SToD(" ")
Harbour supports dates up 9999/12/31 when Clipper only to 2999/12/31
so HB_SToD("99990101") returns valid date but Clipper does not
accept it. If you need strict compatibility then see in
source/common/hbdate.c HB_DATE_YEAR_LIMIT macro.
> ! 594 MAIN_HVMA(341) saArray[ 1000 ]
> Result: "E BASE 1132 Bound error array access A:2:A:{.[1].};N:1000 "
> Expected: "E BASE 1132 Bound error array access "
this and all other errors shows only one difference.
When RT error is generated Harbour nearly always stores in ARGS array of
RTE object parameters passed to function or used in HVM action when Clipper
makes it only in some chosen places. In this case it's:
A:2:A:{.[1].};N:1000
means that in oErr:ARGS you have arrays where first parameter is
saArray and second is: 1000. IMHO it's very nice feature for users
which can check more precisely RTE conditions but it's not strictly
Clipper compatible so hbtest catch it.
> Why hbtest of xarbour is different?
Be carefull with xHarbour hbtest - in some places the epxected results
were hacked to pacify reported warnings instead of making real fix in
core code. Always verify the results with Clipper. Please also remember
that there are differences btween CL52 and CL53 and some thingsa in Harbour
are CL53 compatible and some other C53.
> Is possible recompile hbtest in xharbour?
Probably yes but in Harbour hbtest also tests classes code (rt_class.prg)
and this part will probably show hundreds of errors and finally GPF on
destructors tests. This are old xHarbour bugs I was writing about many
times in the past and I even create test code examples in tests/ directory
but seems that no one in xHarbour devel team is interested in fixing them.
best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
