Waldek Hebisch wrote:
Frank Heckenbach wrote:
First of all, fjf659o.pas is a strange test program anyway. I was wondering about it, and it was on my list of things to have a closer look at again. So if it fails now, I don't consider it serious anyway.
It's supposed to test that `Finalize' does something for files. But what exactly it does, might better be left undefined. So, when the test program checks for a I/O error that can be caught, this might simply be too optimistic. (And file handling has changed internally since it was written, so it's possible that originally, it either caused a bad access that wasn't noticed, as now, or it didn't and does now.)
I think that it is not nice to crash. IMHO we should very clearly state in the documentation that access to a variable after calling `Finalize' on it is illegal,
I'd say so -- that's the purpose of `Finalize' after all. It's meant to be used, e.g., for variables allocated via pointers in memory mapped explicitly for some reason (i.e., not allocated with `New'). Since initialization and clean-up here cannot be done automatically as is done by `New' and `Dispose' (or for non-pointer variables on entry/exit of scope), there has to be an explicit statement. But using the variable after `Finalize' (and before a new `Initialize') should be wrong by definition IMHO. I'm adding a note in the documentation.
BTW, I have plans to change the internal structure of files again (not urgent). These will probably make access after `Finalize' not crash, but treat the file just as closed and unbound. But that's not my primary motivation for the change, and I wouldn't like to officially guarantee that behaviour then either.
Frank