Re: Fix optind handling inconsistency in getopt_long() for missing argument

From: Japin Li <japinli(at)hotmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: PostgreSQL-development <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Fix optind handling inconsistency in getopt_long() for missing argument
Date: 2026-07-22 04:22:06
Message-ID: SY7PR01MB109210E2A46D09049F98D185AB6C12@SY7PR01MB10921.ausprd01.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 22 Jul 2026 at 12:17, Japin Li <japinli(at)hotmail(dot)com> wrote:
> Hi, Michael
>
> Thanks for reviewing the patch.
>
> <#secure method=pgpmime mode=sign>
> On Wed, 22 Jul 2026 at 10:47, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>> On Tue, Jul 21, 2026 at 06:16:27PM +0800, Japin Li wrote:
>>> + place = EMSG;
>>> + optind++;
>>> +
>>> if (optstring[0] == ':')
>>> return BADARG;
>>>
>>> @@ -153,9 +156,6 @@ retry:
>>> "%s: option requires an argument -- %s\n",
>>> argv[0], place);
>>>
>>> - place = EMSG;
>>> - optind++;
>>> -
>>> if (has_arg == required_argument)
>>> return BADCH;
>>> optarg = NULL;
>>
>> This also means that for long options we have an error message would
>> now use an empty string instead of an option name all the time. That
>> looks incorrect.
>
> Right. I was mistaken about the option name. Fixed in v2-0002.
>
>>
>> You are claiming that this makes the short option path more
>> consistent. That's true based on what your patch does, but it also
>> looks to me like the short option area is already wrong in setting
>> EMSG before we issue the error string "option requires an argument".
>> So, to me, you are making the situation worse in some cases while
>> claiming that it improves the situation in some other cases.
>>
>> Our implementation of getopt_long() is only used on Windows for MSVC,
>> as far as I know. I'd also suggest to post one or more examples of
>> how this changes the implementation behavior. You should be able to
>> force your way through easily so as the Postgres getopt_long()
>> implementation is used with a quick hack, just to prove your point,
>> saving you the pain of deploying a WIN32 host.. (Like use a
>> pg_getopt_long() and patch one of the binaries, whatever you prefer.)
>
> Here's a mini‑demo for getopt_long() in v2‑0001. Without v2‑0002, the output is:
>
> $ ./getopt_long_test --log-filename
> option './getopt_long_test' requires an argument
> unrecognized option './getopt_long_test'
> unrecognized option './getopt_long_test'
> unrecognized option './getopt_long_test'
> unrecognized option './getopt_long_test'
> $ ./getopt_long_test -f
> option '-f' requires an argument
>
> With v2‑0002 applied, the output is:
>
> $ ./getopt_long_test --log-filename
> option '--log-filename' requires an argument
> $ ./getopt_long_test -f
> option '-f' requires an argument
>
>> --
>> Michael
>

Sorry, I forgot to include the patches in my previous email.

> --
> Regards,
> Japin Li
> ChengDu WenWu Information Technology Co., Ltd.

--
Regards,
Japin Li
ChengDu WenWu Information Technology Co., Ltd.

Attachment Content-Type Size
v2-0001-Add-a-binary-to-test-getopt_long.patch text/x-patch 2.4 KB
v2-0002-Fix-optind-handling-inconsistency-in-getopt_long-.patch text/x-patch 1.2 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message Shinya Kato 2026-07-22 04:20:29 Re: Track skipped tables during autovacuum and autoanalyze