Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Gary Scott <garylscott@sbcglobal.net>
Newsgroups: comp.lang.fortran
Subject: Re: DEALLOCATE Of Non-ALLOCATEd Should Be No-Op
Date: Wed, 16 Oct 2024 20:57:17 -0500
Organization: A noiseless patient Spider
Lines: 20
Message-ID: <vepqtt$2jh7e$1@dont-email.me>
References: <vepn2d$2f9jq$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 17 Oct 2024 03:57:18 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="19c3a086004d8a7cf5c20c434847a7df";
	logging-data="2737390"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/s9xGU/wTIu7wnrJtqdLsnWbQ6SZBzq1o="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:AksM8JUjqSpSpxMjw8++FY3ERDY=
Content-Language: en-US
In-Reply-To: <vepn2d$2f9jq$1@dont-email.me>
Bytes: 2088

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.