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 <paul@xxxxxxxxxxxxxxx>
> Cc: Hugo Mills <hugo@xxxxxxxxxxxxx>
> Fixes: 010ceab56e06 ("btrfs-progs: rework option parser to use getopt for global options")
> Signed-off-by: Qu Wenruo <wqu@xxxxxxxx>
> ---
> 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?
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
