On 2018年07月03日 06:12, David Sterba wrote:
> On Wed, Jun 20, 2018 at 08:38:38AM +0800, Qu Wenruo wrote:
>> In function handle_global_options(), we reset @optind to 1.
>> However according to man page of getopt(3) NOTES section, if we need to
>> rescan options later, @optind should be reset to 0 to initialize the
>> internal variables correctly.
>>
>> This explains the reason why in cmd_check(), getopt_long() doesn't
>> handle the following command correctly:
>> "btrfs check /dev/data/btrfs --check-data-csum"
>>
>> While mkfs.btrfs handles mixed non-option and option correctly:
>> "mkfs.btrfs -f /dev/data/disk1 --data raid1 /dev/data/disk2"
>>
>> Cc: Paul Jones <p...@pauljones.id.au>
>> Cc: Hugo Mills <h...@carfax.org.uk>
>> Fixes: 010ceab56e06 ("btrfs-progs: rework option parser to use getopt for
>> global options")
>> Signed-off-by: Qu Wenruo <w...@suse.com>
>> ---
>> changelog:
>> v2:
>> Instead of resetting @optind at handle_global_options(), reset @optind
>> before each later getopt() call. Since there are cases uses @optind and
>> expects it to be starting from 1.
>
> So it's not possible to set it once before the callbacks are called in
> btrfs.c:main() due to the exceptions that need it to be set to 1. Ok,
> can you please send a separate patch that makes the optind = 1 explicit?It's already done in handle_global_options(), so every subcommand is getting @optind set to 1 already. Thanks, Qu > Even it might be redundant in the context, it's a way to document the > expected behaviour of getopt and also we would not have to think if the > optind setting is missing or not before the getopts. Thanks. > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
signature.asc
Description: OpenPGP digital signature
