On 7/21/21 10:43 AM, Segher Boessenkool wrote:
On Tue, Jul 20, 2021 at 08:51:58PM -0500, Bill Schmidt wrote:
On 7/20/21 6:22 PM, Segher Boessenkool wrote:
On Tue, Jul 20, 2021 at 05:19:54PM -0500, Bill Schmidt wrote:
See the main function. All three files are guaranteed to have been
opened for writing when this is called, but some of them may have
already been closed. So the fclose calls may fail to do anything, but
the unlinks will always delete the output files. This is done to avoid
leaving garbage lying around after a parsing failure.
That is much worse actually! From the C spec:
The value of a pointer to a FILE object is indeterminate after the
associated file is closed
so this is undefined behaviour.
Please fix that? Just assign 0 after closing, and guard the fclose on
error with that?
No, you're misunderstanding.
unlink doesn't use a pointer to a FILE object. It takes a string
representing the path and deletes that name from the filesystem. If
nobody has the file open, the file is then deleted.
Ah, "the fclose calls may fail to do anything" confused me. That should
never happen (it can get an error, maybe you meant that?)
In this case the files are all always closed before unlink is called.
The names are removed from the filesystem, and the files are deleted.
If somehow the file managed to remain open (really impossible), the file
would not be deleted, but the name would be. No undefined behavior.
Calling fclose on the same FILE * twice is UB. You said you do that,
but that is probably not true?
That is unfortunately true. I guess I'll have to track which files have
been closed, or otherwise make this cleaner. I had misremembered that
duplicate fclose was ignored. :/
Bill
Segher
