Discussion:
DEALLOCATE Of Non-ALLOCATEd Should Be No-Op
(too old to reply)
Lawrence D'Oliveiro
2024-10-17 00:51:26 UTC
Permalink
It’s annoying to find that if you try to DEALLOCATE an ALLOCATABLE
variable that has not been ALLOCATEd (or that has already been
DEALLOCATEd), this is an error.

The usual practice is for storage-disposal calls to be harmless no-ops if
called with a NULL pointer (or equivalent). This is true of the C/POSIX
free(3) call <https://manpages.debian.org/3/free.3.en.html>, for example,
and also for the “delete” statement in C++.

This way, one can simplify cleanup by 1) ensuring all temporary pointers
are initialized to NULL at the start, and 2) unconditionally freeing all
of them at the end.

I suppose Fortran tries to simplify things by handling both conventions
automatically, but this still causes irritations in other places, like
loops.
Gary Scott
2024-10-17 01:57:17 UTC
Permalink
Post by Lawrence D'Oliveiro
It’s annoying to find that if you try to DEALLOCATE an ALLOCATABLE
variable that has not been ALLOCATEd (or that has already been
DEALLOCATEd), this is an error.
The usual practice is for storage-disposal calls to be harmless no-ops if
called with a NULL pointer (or equivalent). This is true of the C/POSIX
free(3) call <https://manpages.debian.org/3/free.3.en.html>, for example,
and also for the “delete” statement in C++.
This way, one can simplify cleanup by 1) ensuring all temporary pointers
are initialized to NULL at the start, and 2) unconditionally freeing all
of them at the end.
I suppose Fortran tries to simplify things by handling both conventions
automatically, but this still causes irritations in other places, like
loops.
The way these things are handled in Fortran is to add a "stat="
specifier. Having a run time error message is standard (meaning
typical) operating behavior for Fortran. I like it that way.
Lawrence D'Oliveiro
2024-10-17 05:54:21 UTC
Permalink
Post by Gary Scott
Post by Lawrence D'Oliveiro
It’s annoying to find that if you try to DEALLOCATE an ALLOCATABLE
variable that has not been ALLOCATEd (or that has already been
DEALLOCATEd), this is an error.
The way these things are handled in Fortran is to add a "stat="
specifier.
But I don’t want to catch errors as a result of invalid, non-NULL pointers
-- let that be trapped as a runtime error as usual. I just want a free of
NULL to be a harmless no-op.

The trouble with “stat=” is like “ON ERROR GOTO” in BASIC of old: you
either catch everything or nothing, you cannot be selective in the
exceptions you catch.
R Daneel Olivaw
2024-10-17 08:12:03 UTC
Permalink
Post by Lawrence D'Oliveiro
Post by Gary Scott
Post by Lawrence D'Oliveiro
It’s annoying to find that if you try to DEALLOCATE an ALLOCATABLE
variable that has not been ALLOCATEd (or that has already been
DEALLOCATEd), this is an error.
The way these things are handled in Fortran is to add a "stat="
specifier.
But I don’t want to catch errors as a result of invalid, non-NULL pointers
-- let that be trapped as a runtime error as usual. I just want a free of
NULL to be a harmless no-op.
The trouble with “stat=” is like “ON ERROR GOTO” in BASIC of old: you
either catch everything or nothing, you cannot be selective in the
exceptions you catch.
Doesn't the content of STAT tell you what the error was?
Lawrence D'Oliveiro
2024-10-17 21:24:17 UTC
Permalink
Post by R Daneel Olivaw
Post by Lawrence D'Oliveiro
The trouble with “stat=” is like “ON ERROR GOTO” in BASIC of old: you
either catch everything or nothing, you cannot be selective in the
exceptions you catch.
Doesn't the content of STAT tell you what the error was?
I’m sure it does.

Loading...