On 3/3/23 3:32 PM, Iain Sandoe wrote:
On 3 Mar 2023, at 23:11, Bernhard Reutner-Fischer via Fortran
<fort...@gcc.gnu.org> wrote:
On 2 March 2023 02:23:10 CET, Jerry D <jvdelis...@gmail.com> wrote:
On 3/1/23 4:07 PM, Steve Kargl via Fortran wrote:
On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via Fortran
wrote:
libgfortran/caf/single.c | 6 ++----
libgfortran/io/async.c | 6 ++----
libgfortran/io/format.c | 3 +--
libgfortran/io/transfer.c | 6 ++----
libgfortran/io/unix.c | 3 +--
The Fortran ones are OK.
The only question I have: Is free posix compliant on all platforms?
For example ming64 or mac?
OSX / macOS are [certified] Posix compliant - but to unix03 (and might be
missing features declared as optional at that revision, or features from later
Posix versions).
In the case of free() man says:
"The free() function deallocates the memory allocation pointed to by ptr. If
ptr is a NULL pointer, no operation is performed.”
Iain
It seems sometimes we run into things like this once in a while.
I think we have the -liberty to cater even for non compliant systems either
way, if you please excuse the pun. That's not an excuse on POSIX systems, imho.
I am certainly not a C++ expert but it seems to me this all begs for
automatic finalization where one would not have to invoke free at all.
I suspect the gfortran frontend is not designed for such things.
Otherwise I have no issue at all. It is a lot cleaner.
Jerry
