Re: [PATCH 04/28] qemu-img: global option processing and error printing

2024-02-26 Thread Michael Tokarev
26.02.2024 18:43, Michael Tokarev wrote: The reason is most likely the argv/argc handling (lack of optind reset). In the later change it is fixed but at that stage it's broken. Nope. GNU getopt_long really needs resetting the state. Or else it keeps return_in_order/permute/etc setting from the

Re: [PATCH 04/28] qemu-img: global option processing and error printing

2024-02-26 Thread Michael Tokarev
26.02.2024 18:40, Daniel P. Berrangé : .. I'm not sure how, but this change seems to have broken the iotests. Just one example: Heh. Thank you for trying that. I wanted to do that but forgot. The reason is most likely the argv/argc handling (lack of optind reset). In the later change it is f

Re: [PATCH 04/28] qemu-img: global option processing and error printing

2024-02-26 Thread Daniel P . Berrangé
On Thu, Feb 22, 2024 at 12:15:45AM +0300, Michael Tokarev wrote: > In order to correctly print executable name in various > error messages, pass argv[0] to error_exit() function. > This way, error messages will refer to actual executable > name, which may be different from 'qemu-img'. > > For subc

Re: [PATCH 04/28] qemu-img: global option processing and error printing

2024-02-26 Thread Daniel P . Berrangé
On Thu, Feb 22, 2024 at 12:15:45AM +0300, Michael Tokarev wrote: > In order to correctly print executable name in various > error messages, pass argv[0] to error_exit() function. > This way, error messages will refer to actual executable > name, which may be different from 'qemu-img'. > > For subc

[PATCH 04/28] qemu-img: global option processing and error printing

2024-02-21 Thread Michael Tokarev
In order to correctly print executable name in various error messages, pass argv[0] to error_exit() function. This way, error messages will refer to actual executable name, which may be different from 'qemu-img'. For subcommands, pass whole argv[] array, so argv[0] is the executable name, not subc