From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id AA92B398D40D for ; Wed, 21 Jul 2021 01:52:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AA92B398D40D Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 16L1Xmm4182590; Tue, 20 Jul 2021 21:52:01 -0400 Received: from ppma04wdc.us.ibm.com (1a.90.2fa9.ip4.static.sl-reverse.com [169.47.144.26]) by mx0b-001b2d01.pphosted.com with ESMTP id 39x5ypnv5m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 20 Jul 2021 21:52:01 -0400 Received: from pps.filterd (ppma04wdc.us.ibm.com [127.0.0.1]) by ppma04wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 16L1fep9028353; Wed, 21 Jul 2021 01:52:00 GMT Received: from b01cxnp22033.gho.pok.ibm.com (b01cxnp22033.gho.pok.ibm.com [9.57.198.23]) by ppma04wdc.us.ibm.com with ESMTP id 39upubnmgr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Jul 2021 01:52:00 +0000 Received: from b01ledav006.gho.pok.ibm.com (b01ledav006.gho.pok.ibm.com [9.57.199.111]) by b01cxnp22033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 16L1pxfH32244128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 21 Jul 2021 01:51:59 GMT Received: from b01ledav006.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DA754AC05B; Wed, 21 Jul 2021 01:51:59 +0000 (GMT) Received: from b01ledav006.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 94ABEAC059; Wed, 21 Jul 2021 01:51:59 +0000 (GMT) Received: from Bills-MacBook-Pro.local (unknown [9.211.140.71]) by b01ledav006.gho.pok.ibm.com (Postfix) with ESMTP; Wed, 21 Jul 2021 01:51:59 +0000 (GMT) Reply-To: wschmidt@linux.ibm.com Subject: Re: [PATCH 10/55] rs6000: Main function with stubs for parsing and output To: Segher Boessenkool Cc: gcc-patches@gcc.gnu.org References: <20210719191524.GP1583@gate.crashing.org> <96c1f140-9600-86a6-276f-2ac8c3fbec38@linux.ibm.com> <20210720232227.GB1583@gate.crashing.org> From: Bill Schmidt Message-ID: <81520718-d8be-d63e-0ee6-6fe21ea4fea4@linux.ibm.com> Date: Tue, 20 Jul 2021 20:51:58 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <20210720232227.GB1583@gate.crashing.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-TM-AS-GCONF: 00 X-Proofpoint-GUID: W6bVagjRHdyBWNZzROuf_C7HSBbyeDdh X-Proofpoint-ORIG-GUID: W6bVagjRHdyBWNZzROuf_C7HSBbyeDdh X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-20_15:2021-07-19, 2021-07-20 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 malwarescore=0 suspectscore=0 bulkscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 phishscore=0 adultscore=0 mlxlogscore=999 priorityscore=1501 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107210006 X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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 01:52:04 -0000 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