From: Tom Lane <tgl@sss.pgh.pa.us>
To: Quentin Rameau <quinq@fifth.space>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [PATCH] Fix missing argument handling in psql getopt
Date: Sun, 25 Aug 2019 12:57:48 -0400
Message-ID: <7842.1566752268@sss.pgh.pa.us> (raw)
In-Reply-To: <20190825175338.74ed0f0e@fifth.space>
References: <20190825100617.GA6087@fifth.space>
<14042.1566745352@sss.pgh.pa.us>
<20190825175338.74ed0f0e@fifth.space>
Quentin Rameau <quinq@fifth.space> writes:
>> Um ... so how would control get there with optind too large?
> That's from the getopt specification[0]:
> “If the option was the last character in the string pointed to by an
> element of argv, then optarg shall contain the next element of argv,
> and optind shall be incremented by 2. If the resulting value of optind
> is greater than argc, this indicates a missing option-argument, and
> getopt() shall return an error indication.”
Hm, interesting --- glibc doesn't seem to do that (advance optind past
argc), nor do any of the principal BSDen. I see that this could be
read as requiring it, but it seems like musl is pretty out of step
by reading it that way.
I actually don't care for that code very much and would prefer that
we nuke it entirely, because I think it's assuming more than it ought to
about the meaning of optind: in the case of multiple option letters in one
argv element, it's unspecified exactly when optind advances. So the other
problem here is that sometimes it's looking at the argv element *before*
the relevant one. (It's easily demonstrated that this is so with glibc's
getopt().) Probably that doesn't ever result in wrong behavior in
practice, but it still seems bogus.
The normal case of "psql -?" is handled before we ever get to this code,
so if we just deleted '?' entirely from this logic, it would mostly do
what we want. The case that would change is, eg,
psql -f foo -?
where now you get a usage message but you'd just get an "invalid option"
complaint without the special case. Seeing that none of our other
command-line programs have this special case, I'm not sure why psql
still does.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, quinq@fifth.space
Subject: Re: [PATCH] Fix missing argument handling in psql getopt
In-Reply-To: <7842.1566752268@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox