Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Lawrence D'Oliveiro <ldo@nz.invalid>
Newsgroups: comp.lang.fortran
Subject: DEALLOCATE Of Non-ALLOCATEd Should Be No-Op
Date: Thu, 17 Oct 2024 00:51:26 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 16
Message-ID: <vepn2d$2f9jq$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 17 Oct 2024 02:51:26 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="9416ba48f1adcfe2127401957dfa62bf";
	logging-data="2598522"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18IziqhdivZ5V1Nn5htKtv7"
User-Agent: Pan/0.160 (Toresk; )
Cancel-Lock: sha1:i9xsFHs1R7yWuDPNEwiBlvxfRMM=
Bytes: 1658

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.