Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.89)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1i1y5B-0000PH-7O
	for pgsql-hackers@arkaria.postgresql.org; Sun, 25 Aug 2019 19:21:45 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.89)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1i1y59-0005ar-Na
	for pgsql-hackers@arkaria.postgresql.org; Sun, 25 Aug 2019 19:21:43 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.89)
	(envelope-from <quinq@fifth.space>)
	id 1i1y59-0005ak-FB
	for pgsql-hackers@lists.postgresql.org; Sun, 25 Aug 2019 19:21:43 +0000
Received: from fifth.space ([45.32.148.28])
	by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.89)
	(envelope-from <quinq@fifth.space>)
	id 1i1y57-0000ox-8i
	for pgsql-hackers@lists.postgresql.org; Sun, 25 Aug 2019 19:21:43 +0000
Received: from fifth.space (localhost [127.0.0.1])
	by fifth.space (OpenSMTPD) with ESMTP id d958445e;
	Sun, 25 Aug 2019 21:21:39 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=fifth.space; h=date:from
	:to:cc:subject:message-id:in-reply-to:references:mime-version
	:content-type; s=dkim; bh=BJh3XiK5aBR5DVESSkLJYY2atjg=; b=Zata7u
	SNuUD2c6Y7NIbfhhlPBSwxvsVS1IzZ8yW3tFNYJbTjjzBgCwHEfXpkaet70/qH34
	L8klOQwTMPkhCSzN8G1baa4fpWJqkcKZmaiP7FetJ/iPEnI57/P3lf5EntK8kpcB
	7xXQayky3fFCy4ozRQi0R4gfrd6THO5QlsNluNfviUFcOZjzgLPY6sxFhNoTlnZL
	+bPBw6L4bl/nfd/W+4RZ4ukVMARncJH/Ffpw4Vwdzq4qzA9OAyEa1BH2OWdgTUim
	QbHweCbULsR/UR3/BUmkxnkkIfekRp/2k2vVI+QtGNtrdcudiZlonGIG6SkiLM6Z
	lSw/e6+TDcst2X3g==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=fifth.space; h=date:from:to
	:cc:subject:message-id:in-reply-to:references:mime-version
	:content-type; q=dns; s=dkim; b=kdFA4/IdY54/XsZG3n8JxxDWy6BrzMEX
	6WBMT5DdKikIMI50az+l0L/vIh3ZhNQ6Twu7Qho36MHl4e3/JGUvaY17iky4EysS
	lQNO+Ue+UVOdBa1tO1lj0s990OdQGuvUVzjV43U24VOxblsZ8d4FdW47HxoBD2Dn
	4MJoAQEIix32x7k2R4QNZERujmyPvhrF10NQ/ZRwmTF+4HofdeYDpjJW22bm70W8
	5h5/f2DnwDaPQaAn9FMwiJhCYDRR6BZQu7+ZDnpZPGigj6E1loU7knRhRa4BZSjc
	sTrNuvc3312879yFZAZ17gyDzyttdPlIhFSirCWoZO8Qj1VW9AwssA==
Received: from localhost.localdomain (<unknown>
 [IPv6:2a01:e34:ecae:2d51:29d6:6297:bd67:8dee])
	by fifth.space (OpenSMTPD) with ESMTPSA id 076c469a
 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO);
	Sun, 25 Aug 2019 21:21:38 +0200 (CEST)
Date: Sun, 25 Aug 2019 21:21:36 +0200
From: Quentin Rameau <quinq@fifth.space>
To: pgsql-hackers@lists.postgresql.org
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: [PATCH] Fix missing argument handling in psql getopt
Message-ID: <20190825212136.04b56ac3@fifth.space>
In-Reply-To: <20190825210009.586cfd5c@fifth.space>
References: <20190825100617.GA6087@fifth.space>
	<14042.1566745352@sss.pgh.pa.us>
	<20190825175338.74ed0f0e@fifth.space>
	<7842.1566752268@sss.pgh.pa.us>
	<20190825210009.586cfd5c@fifth.space>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="MP_/oEcYY8373P4jignUOgMh8T."
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Precedence: bulk

--MP_/oEcYY8373P4jignUOgMh8T.
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

> Another better way, I think, to fix this is to check for optopt
> instead, which would be set to the option which caused the error, which
> if empty means there isn't an error.
> 
> Patch attached.

Actually OpenBSD seems to set optopt to '?' by default, so the updated
attached patch ensure we start with an empty optopt.

--MP_/oEcYY8373P4jignUOgMh8T.
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=0001-Fix-handling-of-option.patch

From ba0b331e67db4eb1a66ee7a1445a536f9788f0ad Mon Sep 17 00:00:00 2001
From: Quentin Rameau <quinq@fifth.space>
Date: Sun, 25 Aug 2019 20:45:29 +0200
Subject: [PATCH] Fix handling of ? option

Using optind to check back the original given option this way is bogus
and could lead to dereferencing argv out of bounds with a missing
argument to an option.

The proper way to verify if an error has occured is to check if optopt
has been set.
---
 src/bin/psql/startup.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/bin/psql/startup.c b/src/bin/psql/startup.c
index 4730c73396..333b49985a 100644
--- a/src/bin/psql/startup.c
+++ b/src/bin/psql/startup.c
@@ -507,6 +507,7 @@ parse_psql_options(int argc, char *argv[], struct adhoc_opts *options)
 	int			c;
 
 	memset(options, 0, sizeof *options);
+	optopt = 0;
 
 	while ((c = getopt_long(argc, argv, "aAbc:d:eEf:F:h:HlL:no:p:P:qR:sStT:U:v:VwWxXz?01",
 							long_options, &optindex)) != -1)
@@ -667,7 +668,7 @@ parse_psql_options(int argc, char *argv[], struct adhoc_opts *options)
 				break;
 			case '?':
 				/* Actual help option given */
-				if (strcmp(argv[optind - 1], "-?") == 0)
+				if (!optopt)
 				{
 					usage(NOPAGER);
 					exit(EXIT_SUCCESS);
-- 
2.23.0


--MP_/oEcYY8373P4jignUOgMh8T.--