BTW: Frank and Peter - the "Readln" bug still exists under DJGPP.
This is my workaround; Readln ( MyText, s ); i := length ( s ); if s [ i ] = #13 then Delete ( s, i, 1);
I am not sure whether the fact that "s" contains the #13 character at the end of it is a GPC problem, or a DJGPP problem.
Strange -- I can't see this bug! I got the binary distribution of gpc-980511 (*) for DJGPP, and tested the following program.
(*) The files are dated 11 May -- though GPC gives 2.8.1 as its version number (under Linux as well). Is this correct, Peter?
program Chief23; var t:text; s:string(42); begin rewrite(t,'test.dat'); writeln(t,'OK'); reset(t); readln(t,s); if length(s)=2 then writeln(s) else writeln('Failed: ',length(s),' ',s); close(t) end.
It writes "OK", though test.dat clearly contains a #13 before the #10.
So, if this bug still shows on your system, it must depend on the presence of DosEmu (but why should it?), the version of DJGPP or the phase of the moon. Can anyone else reproduce it?
Frank
According to Frank Heckenbach:
(*) The files are dated 11 May -- though GPC gives 2.8.1 as its version number (under Linux as well). Is this correct, Peter?
Sort of. I would prefer to let GPC output something like "gpc-980511 (gcc-2.8.1)", but this caused "Abort!"s under every system execpt Linux, so I changed it. (But the problem did not vanish completely, did it?)-:
It writes "OK", though test.dat clearly contains a #13 before the #10.
So it does for me.
So, if this bug still shows on your system, it must depend on the presence of DosEmu (but why should it?), the version of DJGPP or the phase of the moon. Can anyone else reproduce it?
It could also be an old version of `libgpc.a' somewhere in the library path.
Peter