On Fri, 2 Apr 2004, Frank Heckenbach wrote:
Emil Jerabek wrote:
On Fri, Apr 02, 2004 at 12:59:30PM +0200, Frank Heckenbach wrote:
Hi,
there's a strange case when using relative file names and changing the directory. (Incidentally I was made aware of this by a bugfix in the ncurses library (C code) some while ago ... ;-) Consider this program:
program Foo;
var i: Integer; f: Text;
begin Assign (f, 'test.dat'); Rewrite (f); WriteLn (f, 42); Close (f); ChDir ('..'); Reset (f); ReadLn (f, i); WriteLn (i) end.
It fails under both GPC and BP because `Reset' tries to open a file `test.dat' in a different directory than it was created.
[...]
How do other compilers behave? What would be the expected behaviour of code like above if it actually occurs in practice?
Frank
IMHO this is quite natural. There's no reason to close the file if I want its "identity" to be preserved.
I'm not sure. I'd rather consider `Assign' to be "identity giving" in this context. BTW, without closing it works under GPC and still fails under BP.
Frank
Would be interesting to know if there are any standards on this (Is Scott Moore paying any attention?)... my own view would be that once a file is open, it's open and you ought to be able access it even if you change directories and even if someone else changes the name of the file (which is one of the reasons why OS' generally only allow one process write access to a file at a time). File name assignments, on the other hand, should be relative to the current directory; thus, in the example above, the program should try to open "test.dat" in the current directory both times (2 different files, unless they're linked).
-------------------------| John L. Ries | Salford Systems | Phone: (619)543-8880 x25 | (760)765-4738 | Cell: (760)445-6122 | -------------------------