From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v2 0/2] btrfs-progs: parser related cleanups
Date: Thu, 18 Jan 2024 09:40:41 +1030 [thread overview]
Message-ID: <cover.1705532789.git.wqu@suse.com> (raw)
[CHANGELOG]
v2:
- Properly return the parsed value for parse_u64_with_suffix()
Facepalm, I forgot to assign the result to @value_ret, and only relied
on cli-tests to catch them, but they are not enough to catch.
- Avoid outputting any error message inside parse_u64_with_suffix()
One error message and exit(1) call is left from previous function.
Need to be consistent with all other error situations.
- Rebased using the patch from devel branch
So that the modification David did won't need to be redone.
Btrfs-progs has two types of parsers:
- parse_*()
Those would return 0 for a good parse, and save the value into a
pointer.
Callers are responsible to handle the error.
- arg_strto*()
Those would directly return the parsed value, and call exit(1)
directly for errors.
However this split is not perfect:
- A lot of code can be shared between them
In fact, mostly arg_strto*() can be implement using parse_*().
The only difference is in how detailed the error string would be.
- parse_size_from_string() doesn't follow the scheme
It follows arg_strto*() behavior but has the parse_*() name.
This patch would:
- Use parse_u64() to implement arg_strtou64()
The first patch.
- Use parse_u64_with_suffix() to implement arg_strtou64_with_suffix()
The new helper parse_u64_with_suffix() would replace the old
parse_size_from_string() and do the proper error handling.
Qu Wenruo (2):
btrfs-progs: use parse_u64() to implement arg_strtou64()
btrfs-progs: implement arg_strtou64_with_suffix() with a new helper
cmds/filesystem.c | 15 ++++----
cmds/qgroup.c | 3 +-
cmds/reflink.c | 7 ++--
cmds/scrub.c | 2 +-
common/parse-utils.c | 90 +++++++++++++++++++++++++++----------------
common/parse-utils.h | 2 +-
common/string-utils.c | 45 ++++++++++++++--------
common/string-utils.h | 9 +++++
convert/main.c | 3 +-
kernel-shared/zoned.c | 4 +-
mkfs/main.c | 6 +--
11 files changed, 118 insertions(+), 68 deletions(-)
--
2.43.0
WARNING: multiple messages have this Message-ID (diff)
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v2 0/2] btrfs-progs: parser related cleanups
Date: Thu, 18 Jan 2024 09:44:52 +1030 [thread overview]
Message-ID: <cover.1705532789.git.wqu@suse.com> (raw)
Message-ID: <20240117231452.Czo0ujKetBWVo1SO-RJbq_58FKn7ztu9_rr0Vh5YP4w@z> (raw)
[CHANGELOG]
v2:
- Properly return the parsed value for parse_u64_with_suffix()
Facepalm, I forgot to assign the result to @value_ret, and only relied
on cli-tests to catch them, but they are not enough to catch.
- Avoid outputting any error message inside parse_u64_with_suffix()
One error message and exit(1) call is left from previous function.
Need to be consistent with all other error situations.
- Rebased using the patch from devel branch
So that the modification David did won't need to be redone.
Btrfs-progs has two types of parsers:
- parse_*()
Those would return 0 for a good parse, and save the value into a
pointer.
Callers are responsible to handle the error.
- arg_strto*()
Those would directly return the parsed value, and call exit(1)
directly for errors.
However this split is not perfect:
- A lot of code can be shared between them
In fact, mostly arg_strto*() can be implement using parse_*().
The only difference is in how detailed the error string would be.
- parse_size_from_string() doesn't follow the scheme
It follows arg_strto*() behavior but has the parse_*() name.
This patch would:
- Use parse_u64() to implement arg_strtou64()
The first patch.
- Use parse_u64_with_suffix() to implement arg_strtou64_with_suffix()
The new helper parse_u64_with_suffix() would replace the old
parse_size_from_string() and do the proper error handling.
Qu Wenruo (2):
btrfs-progs: use parse_u64() to implement arg_strtou64()
btrfs-progs: implement arg_strtou64_with_suffix() with a new helper
cmds/filesystem.c | 15 ++++----
cmds/qgroup.c | 3 +-
cmds/reflink.c | 7 ++--
cmds/scrub.c | 2 +-
common/parse-utils.c | 90 +++++++++++++++++++++++++++----------------
common/parse-utils.h | 2 +-
common/string-utils.c | 45 ++++++++++++++--------
common/string-utils.h | 9 +++++
convert/main.c | 3 +-
kernel-shared/zoned.c | 4 +-
mkfs/main.c | 6 +--
11 files changed, 118 insertions(+), 68 deletions(-)
--
2.43.0
next reply other threads:[~2024-01-17 23:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-17 23:10 Qu Wenruo [this message]
2024-01-17 23:14 ` [PATCH v2 0/2] btrfs-progs: parser related cleanups Qu Wenruo
2024-01-17 23:10 ` [PATCH v2 1/2] btrfs-progs: use parse_u64() to implement arg_strtou64() Qu Wenruo
2024-01-17 23:14 ` Qu Wenruo
-- strict thread matches above, loose matches on Subject: below --
2024-01-17 23:17 [PATCH v2 0/2] btrfs-progs: parser related cleanups Qu Wenruo
2024-01-18 1:16 ` David Sterba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1705532789.git.wqu@suse.com \
--to=wqu@suse.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.