Hi gents,
I'll add a test case for ASORT() plus a comment to the
AEVAL() test as below, and exclude it to not pollute our
hbtest results.
Brgds,
Viktor
On 2008.09.08., at 21:33, Przemyslaw Czerpak wrote:
On Mon, 08 Sep 2008, Saulius Zrelskis wrote:
Hi Saulius,
It seems that Clipper use a cloned copy of the original array to
do the
loop,
and supply these orininal values to the codeblock. Bug or a feature?
Clipper uses original array, but <nCount> value calculates before
loop
through array
and never recalculated. After resizing array run garbage collection
(Memory(
-1 )) and see what's happening...
Exactly. It's a bug in Clipper. In the moment when garbage collector
is
activated directly by memory(-1) or indirectly by heavy memory usage
or
or VM (evaluated pcode counter or asynchronous event like interrupt)
Clipper GPFs with this code so it's not safe in Clipper to create and
execute such constructions.
In Harbour it's safe but resize operation immediately effects AEVAL()/
ASCAN() range. IMHO it's OK. We should only fix ASORT() which is not
safe and GPFs when sort block resize the array.
In xHarbour Clipper's behavior is partially emulated but not exactly
and it's even possible to create exploit for this emulation which
will cause GPF.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
