Sorry, forgot to thank you for your extremely thorough answer! I included it on http://209.97.219.2/sjohnson/ with props to your nickname. Thanks again.
2010/1/22 Przemysław Czerpak <[email protected]> > 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 > -- smu johnson <[email protected]> _______________________________________________ Harbour-users mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour-users
