Bug in TPL60N19 (Norbert Juffa's RTL replacent for TP6 RTL)


Mike Monet once sent me a private email about a problem he encountered with
Norbert Juffa's replacement for the TP6 RTL, when using, AFAIR, XMS or EMS. I
don't know if this is the same problem, but it took me about 2 hours to find
this one.

As usual I was converting Pascal to BASM, and suddenly a routine started
giving me runtime errors 204, even though the BASM code was a straight copy of
code from the TD log... Well actually it wasn't, as I was using the EAX
register to copy a 4-byte string to a array[1..4] of char, instead of using an
assignment, which uses the RTL move() routine. When using both the new BASM
code followed by the old Pascal code the routine worked without any problems,
and in both cases the array contained the correct data, and did so for the
entire input file. It was only at the final stages, when the routine started
disposing getmem'ed storage that the 204 appeared.

I was quite puzzled, but eventually tracked the bug down to an overlapping
move() futher down the reading loop. To do such a move, it has to be done from
top to bottom, and this means executing an STD instruction to set the
direction flag, which Norbert unfortunately forgot to clear it afterwards.
Using move() to move the string into an array (a non-overlapping move) would
reset the direction flag, but my move via EAX didn't, and as a result a later
dispose(), which uses movsw screws up the free list and/or heap. (I haven't
bothered to find out which of the two)

There might be a way to patch Norbert's RTL, if not all I can suggest is that
you don't use dispose() immediately after an overlapping move, or always
precede dispose() by


or create an inline procedure:

procedure cld; inline($FC);

and call it before dispose() if there is a possebility of a preceding
overlapping move.

Robert AH Prins

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading