[4.x] Close stream first, close fd only if not stream

[ddeclerck]

This PR attemps to fix a debug assertion occuring under the MSVC CI (Assertion failed: (_osfile(fh) & FOPEN)).

Apparently, when a stream is created from a file descriptor via fdopen, it should always be closed by fclose. This is not always the case in the 4.x branch. While this seems to fail silently on most OSes, it triggers a debug assertion under MSVC debug.

This proposed fix just always tries to close the stream if it is not NULL, otherwise it just closes the file descriptor.
This fixes 40 (!) tests under MSVC debug.

References:

• Linux: https://linux.die.net/man/3/fdopen
• Windows: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/fdopen-wfdopen?view=msvc-170
• BSD: https://man.freebsd.org/cgi/man.cgi?query=fdopen&sektion=3&n=1
• macOS: https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/fdopen.3.html
• IBM: https://www.ibm.com/docs/en/i/7.5?topic=functions-fdopen-associates-stream-file-descriptor

[GitMensch]

I wonder why this seems to be no issue in 3.x and if valgrind will report more leaks afterwards.
In any case, please adjust that first "if" (and therefore re-indent the not-yet changed code).

[ddeclerck]

I wonder why this seems to be no issue in 3.x

Because in 3.x cob_fd_file_open never creates streams from the given file descriptors, and so we have the invariant that only (and all) LS files have a stream. The cleanup code for LS files always tries to close the stream, while the cleanup code for non-LS files always tries to close the file descriptor.

In 4.x cob_fd_file_open does create streams from the given file descriptors, and the cleanup code ends up directly closing those file descriptors.

[ddeclerck]

I wonder if valgrind will report more leaks afterwards

So, after checking, no change in the number of leaks.

[GitMensch]

this means that you can drop your "should" comment along with adjusting that if, then push the result upstream

[ddeclerck]

Merged in SVN @ 5442.