GPC ALPHA 20050217 released

[Frank Heckenbach]

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

-- 
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