Re: add non-option reordering to in-tree getopt_long
От | Kyotaro Horiguchi |
---|---|
Тема | Re: add non-option reordering to in-tree getopt_long |
Дата | |
Msg-id | 20230615.143034.1555041904838122564.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: add non-option reordering to in-tree getopt_long (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: add non-option reordering to in-tree getopt_long
|
Список | pgsql-hackers |
At Wed, 14 Jun 2023 15:46:08 -0700, Nathan Bossart <nathandbossart@gmail.com> wrote in > On Wed, Jun 14, 2023 at 03:11:54PM -0700, Noah Misch wrote: > > Here's some output from this program (on AIX 7.1, same output when compiled > > 32-bit or 64-bit): > > > > $ ./a.out a b c d e f > > f e d c b a ./a.out > > Thanks again. > > > Interesting discussion here, too: > > https://github.com/libuv/libuv/pull/1187 > > Hm. IIUC modifying the argv pointers on AIX will modify the process title, > which could cause 'ps' to temporarily show duplicate/missing arguments > during option parsing. That doesn't seem too terrible, but if pointer > assignments aren't atomic, maybe 'ps' could be sent off to another part of > memory, which does seem terrible. Hmm, the discussion seems to be based on the assumption that argv[0] can be safely redirected to a different memory location. If that's the case, we can prpbably rearrange the array, even if there's a small window where ps might display a confusing command line, right? regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: