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 3AC17385E82D for ; Tue, 20 Jul 2021 23:23:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3AC17385E82D 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 16KNMRdu005838; Tue, 20 Jul 2021 18:22:27 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 16KNMRat005837; Tue, 20 Jul 2021 18:22:27 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Tue, 20 Jul 2021 18:22:27 -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: <20210720232227.GB1583@gate.crashing.org> References: <20210719191524.GP1583@gate.crashing.org> <96c1f140-9600-86a6-276f-2ac8c3fbec38@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: <96c1f140-9600-86a6-276f-2ac8c3fbec38@linux.ibm.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-6.0 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: Tue, 20 Jul 2021 23:23:29 -0000 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? > >>+ 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