Re: [PATCH] Fix missing argument handling in psql getopt - Mailing list pgsql-hackers

From Quentin Rameau
Subject Re: [PATCH] Fix missing argument handling in psql getopt
Date
Msg-id 20190825175338.74ed0f0e@fifth.space
Whole thread Raw
In response to Re: [PATCH] Fix missing argument handling in psql getopt  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] Fix missing argument handling in psql getopt  (Quentin Rameau <quinq@fifth.space>)
Re: [PATCH] Fix missing argument handling in psql getopt  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hello Tom,

> > When passing an argument option with a missing argument, strcmp
> > would be called with the argv terminating NULL.
>
> 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.”

So in the case of “psql -h“, optarg points to argv[2] and optind is set
to 3 (optind is initialized to 1, then incremented by 2).

> What test case/platform are you considering?

Test case is just running psql -h.
The bug has been exposed by testing psql on musl.

> (There really shouldn't be *any* case where getopt advances
> optind past argc, imo.)

Actually that's the typical error case, as per the specification quoted
above.

[0] https://pubs.opengroup.org/onlinepubs/9699919799/functions/getopt.html



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: mingw32 floating point diff
Next
From: Quentin Rameau
Date:
Subject: Re: [PATCH] Fix missing argument handling in psql getopt