On Fri, 22 Jan 2010, Bruno Luciani wrote:
Hi,
> This is my test in UBuntu 9.10 32 bits , givme an error too
> but all works ok here , I don't know why the test program generates
> the error
These are not real errors.
hbtest is regression test which compares Clipper and Harbour results
for different language constructions and also checks if some of Harbour
extensions gives expected results.
We haven't replicated Clipper bugs and limitations so it's expected that
some of these test will report differences to Clipper. Usually we pacify
them though in some cases they are intentionally left just to show the
difference.
i.e.:
> ! 612 MAIN_HVMA(373) saArray[ 1000 ]
> Result: "E 2 BASE 1132 Bound error (array access) OS:0 #:0
> A:2:A:{.[1].};N:1000"
> Expected: "E 2 BASE 1132 Bound error (array access) OS:0 #:0
In Clipper ("Expected:") the RTE does not contain the reference to the array
and index. In Harbour the RTE is extended and HVM pass original array, index
and value in assign operation in ARGS error object item so user can catch
such RTE and create his own action for it, i.e. emulate hash arrays or return
some default value instead of RTE.
> ! 742 MAIN_HVMA(542) RTSTR( 00000500000000000000 )
> Result: " 16 500000000000000"
> Expected: " 21 500000000000000"
In Clipper and Harbour in PCODE only double values can store the number
size and integer values are stored without it. Because Harbour support
64bit integer this behavior is extended to numbers over 2^31 and creates
above difference between Harbour and Clipper. In the past I decided that
it's too minor problem to introduce separate PCODE which will store the
size with 64bit integers which can be used to pacify this difference.
> ! 1087 MAIN_MATH(359) Str(1234567890 * 1234567890 )
> Result: " 1524157875019052100"
> Expected: " 1524157875019052000"
In Harbour the result is 64bit integer and in Clipper which supports only
32bit integers it has to be stored in double item.
64bit integers have better precision (~20 decimal digits) then IEEE758
double values (~16 decimal digits) and you can see the difference in
this test. Harbour shows the correct result when in Clipper only 16
digit are significant for formatting strings with result.
> ! 3056 MAIN_ARRAY(395) TAEVSM()
> Result: "N10N 9N 8N 7N 6 5"
> Expected: "N10N 9N 8N 7N 6N 5N 4N 3N 2N 1 0"
This tests exploits some problems in Clipper internals which can also
effect some .prg code which needs such side effects. In this example
not existing items are accessed by Clipper because AEVAL() ignores the
fact that array was dynamically cut by evaluated codeblock. In Clipper
it may even cause internal VM structures corruption if codeblock activates
garbage collector. In Harbour such problem does not exists because
AEVAL() respects dynamically modified array size.
> ! 3178 MAIN_MISC(94) Set( 40 )
> Result: 0
> Expected: NIL
Unimplemented CL5.3 LIGHTLIB setting. We intentionally return NIL to
indicate the fact that LIGHTLIB is not part of Harbour.
best regards,
Przemek
_______________________________________________
Harbour-users mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour-users
