> On 3 Mar 2023, at 23:11, Bernhard Reutner-Fischer via Fortran
> <fortran@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.
>
>>
>> Otherwise I have no issue at all. It is a lot cleaner.
>>
>> Jerry
