Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1opy5g-00024M-64 for pgsql-hackers@arkaria.postgresql.org; Tue, 01 Nov 2022 20:42:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1opy4h-0005SE-2G for pgsql-hackers@arkaria.postgresql.org; Tue, 01 Nov 2022 20:41:31 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1opy4g-0005S5-Ow for pgsql-hackers@lists.postgresql.org; Tue, 01 Nov 2022 20:41:30 +0000 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1opy4e-0000WQ-5h for pgsql-hackers@postgresql.org; Tue, 01 Nov 2022 20:41:29 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id F261E3200077; Tue, 1 Nov 2022 16:41:26 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 01 Nov 2022 16:41:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1667335286; x= 1667421686; bh=O/UOyaXAs1rV969S9TvR1SYspBzBtZDSl+MqiTbQjek=; b=u DwFU9s1teAC4FKzbOgQ5nIUn3kJ9mD83LrGwdKm6RmtchEhC/KDAybCwwZTRQLDn IK2Zomwb11MGJP1BBTF1noBZXuKd+BE4HnSNijzpj0ZJCiDHEdQ+Vvy91ng26Pk0 9cLLuDl5tAzae9BoOR0q6qjeBoUKSQsb3kLz3XTPLFk/P0p8Xk42s2uJesbecDwt 9nNki3yR7ypKG50F5U0069y/8/ZVfkdk7h2fC6gWg4KSYv8TuBN98JarFib50zS3 QPKHM00ZdQBlhedWlQEHSt/QnCtUoQjJ75TnCPfvFOQ3VjQoPZKZ+Od85h5o5RDC qaabq4Ku5EGBM6ORjwKmA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrudehgddugedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpefrvght vghrucfgihhsvghnthhrrghuthcuoehpvghtvghrrdgvihhsvghnthhrrghuthesvghnth gvrhhprhhishgvuggsrdgtohhmqeenucggtffrrghtthgvrhhnpeehleffgeegudejteei hfelteduvdeifffhffdvjedvffegjeekudeludehudeifeenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpvghtvghrrdgvihhsvghnthhrrghu thesvghnthgvrhhprhhishgvuggsrdgtohhm X-ME-Proxy: Feedback-ID: i131946ab:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 1 Nov 2022 16:41:21 -0400 (EDT) Message-ID: <175ef638-32c7-1a84-590c-6df7497baeea@enterprisedb.com> Date: Tue, 1 Nov 2022 16:41:15 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: Check return value of pclose() correctly Content-Language: en-US To: Tom Lane , Michael Paquier Cc: pgsql-hackers References: <8cd9fb02-bc26-65f1-a809-b1cb360eef73@enterprisedb.com> <1091330.1667281922@sss.pgh.pa.us> From: Peter Eisentraut In-Reply-To: <1091330.1667281922@sss.pgh.pa.us> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 01.11.22 06:52, Tom Lane wrote: > I think there are two issues here. POSIX says > > Upon successful return, pclose() shall return the termination status > of the command language interpreter. Otherwise, pclose() shall return > -1 and set errno to indicate the error. > > That is, first you need to make sure that pclose returned a valid > child process status, and then you need to decode that status. > It's not obvious to me that -1 is disjoint from the set of possible > child statuses. Do we need to add some logic that clears and then > checks errno? This return convention is also used by system() and is widely used. So I don't think we need to be concerned about this. In practice, int is 4 bytes and WEXITSTATUS() and WTERMSIG() are one byte each, so they are probably in the lower bytes, and wouldn't accidentally make up a -1. > Also, we have a number of places --- at least FreeDesc() and > ClosePipeStream() --- that consider pclose()'s return value to be > perfectly equivalent to that of close() etc, because they'll > return either one without telling the caller which is which. > It seems like we have to fix that if we want to issue sane > error reports. I think this works. FreeDesc() returns the pclose() exit status to ClosePipeStream(), which returns it directly. No interpretation is done within these functions.