From Newsgroup: comp.lang.fortran

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.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.fortran

On 10/16/2024 7:51 PM, Lawrence D'Oliveiro wrote:

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.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.fortran

On Wed, 16 Oct 2024 20:57:17 -0500, Gary Scott wrote:

On 10/16/2024 7:51 PM, Lawrence D'Oliveiro wrote:

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.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.fortran

Lawrence D'Oliveiro wrote:

On Wed, 16 Oct 2024 20:57:17 -0500, Gary Scott wrote:

On 10/16/2024 7:51 PM, Lawrence D'Oliveiro wrote:

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?
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.fortran

On Thu, 17 Oct 2024 10:12:03 +0200, R Daneel Olivaw wrote:

Lawrence D'Oliveiro wrote:

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.
--- Synchronet 3.20a-Linux NewsLink 1.114