Re: [PATCH 10/55] rs6000: Main function with stubs for parsing and output

[Bill Schmidt <wschmidt@linux.ibm.com>]

On 7/20/21 6:22 PM, Segher Boessenkool wrote:
> Hi!
>
> 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.

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.

Thanks,
Bill

>>>> +  pgm_path = argv[0];
>>> This isn't portable (depending on what you use it for -- argv[0] is not
>>> necessarily a path at all).
>> The only thing it's used for is as a documentation string in the output
>> files, indicating the path to the program that built them. So long as
>> argv[0] is a NULL-terminated string, which it had better be, this is
>> harmless.
> It is allowed to be a null pointer as well.  (gfortran does not work on
> systems that do that, so I wouldn't worry to much about it, but still).
>
>> ISO C11:  "If the value of|argc|is greater than zero, the string pointed
>> to by|argv[0]|represents the program name;|argv[0][0]|shall be the null
>> character if the program name is not available from the host environment."
>>
>> So I think we're good here.
> Yup, we'll survive, argc > 0 pretty much everywhere (but technically it
> isn't even required by POSIX afaics).
>
> Thanks,
>
>
> Segher