Possible bug in `ReadStr'/`Val'

[Frank Heckenbach]

Waldek Hebisch wrote:

> Frank Heckenbach wrote:
> > Waldek Hebisch wrote:
> <snip> 
> > > but with this specification the fix
> > > would be to change the third parameter to StringTFDD_Reset into a var
> > > parameter.
> > 
> > That's why I did so.
>
> I mean that to fix StringTFDD_Reset the rest of the patch is not needed. 

Perhaps the previous code was not strictly wrong, but it was quite
fragile. It relied on a temp copy made during parameter conversion
for the internal call to ReadStr_Init to last over subsequent calls.
(Besides, the new code might produce somewhat more efficient code,
as it avoids a few unnecessary copies. As you said, the other bug,
where a necessary copy isn't made, is independent of my patch.)

> And I just checked that full patch caused regression in fjf629e.pas and
> fjf629g.pas

The patch shouldn't change anything about FormatString (except a
detail for CString parameters, which don't occur here).

I also ran the tests, and it didn't fail (with my current code and
with 20051116). Perhaps it interfered with your recent changes WRT
StringOf? Otherwise it seems to be a somewhat volatile bug, but I
don't yet see it. Which regressions do you get?

... Did you rebuild the RTS as I wrote in my original mail? I now
did some experiments -- indeed, if I build 20051116 without the
patch, then apply the patch, make again without rebuilding the RTS,
I get those failures. But these are then simply due to an
inconsistent compiler/RTS, I suppose.

Frank

-- 
Frank Heckenbach, frank at g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE  D101 CD02 4C9D 0FE0 E5E8