From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id C0F2B3858402 for ; Wed, 21 Jul 2021 15:44:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C0F2B3858402 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 16LFhEl5024390; Wed, 21 Jul 2021 10:43:14 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 16LFhDNN024385; Wed, 21 Jul 2021 10:43:13 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 21 Jul 2021 10:43:13 -0500 From: Segher Boessenkool To: Bill Schmidt Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH 10/55] rs6000: Main function with stubs for parsing and output Message-ID: <20210721154313.GG1583@gate.crashing.org> References: <20210719191524.GP1583@gate.crashing.org> <96c1f140-9600-86a6-276f-2ac8c3fbec38@linux.ibm.com> <20210720232227.GB1583@gate.crashing.org> <81520718-d8be-d63e-0ee6-6fe21ea4fea4@linux.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <81520718-d8be-d63e-0ee6-6fe21ea4fea4@linux.ibm.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, TXREP, T_SPF_HELO_PERMERROR, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2021 15:44:16 -0000 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? Segher