From: David Disseldorp <ddiss@suse.de>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Qu Wenruo <wqu@suse.com>,
linux-btrfs@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] lib/strtox: introduce kstrtoull_suffix() helper
Date: Tue, 19 Dec 2023 14:17:26 +1100 [thread overview]
Message-ID: <20231219141726.5c1e01bd@echidna> (raw)
In-Reply-To: <3ca2a681-79c1-4478-b17f-3128a7018b2d@gmx.com>
On Tue, 19 Dec 2023 06:22:42 +1030, Qu Wenruo wrote:
> On 2023/12/18 23:29, David Disseldorp wrote:
> > Hi Qu,
> >
> > On Fri, 15 Dec 2023 19:09:23 +1030, Qu Wenruo wrote:
> >
> [...]
> >> +/**
> >> + * kstrtoull_suffix - convert a string to ull with suffixes support
> >> + * @s: The start of the string. The string must be null-terminated, and may also
> >> + * include a single newline before its terminating null.
> >> + * @base: The number base to use. The maximum supported base is 16. If base is
> >> + * given as 0, then the base of the string is automatically detected with the
> >> + * conventional semantics - If it begins with 0x the number will be parsed as a
> >> + * hexadecimal (case insensitive), if it otherwise begins with 0, it will be
> >> + * parsed as an octal number. Otherwise it will be parsed as a decimal.
> >> + * @res: Where to write the result of the conversion on success.
> >> + * @suffixes: A string of acceptable suffixes, must be provided. Or caller
> >> + * should use kstrtoull() directly.
> >
> > The suffixes parameter seems a bit cumbersome; callers need to provide
> > both upper and lower cases, and unsupported characters aren't checked
> > for. However, I can't think of any better suggestions at this stage.
> >
>
> Initially I went bitmap for the prefixes, but it's not any better.
>
> Firstly where the bitmap should start. If we go bit 0 for "K", then the
> code would introduce some difference between the bit number and left
> shift (bit 0, left shift 10), which may be a little confusing.
>
> If we go bit 1 for "K", the bit and left shift it much better, but bit 0
> behavior would be left untouched.
>
> Finally the bitmap itself is not that straightforward.
One benefit from a bitmap would be that unsupported @suffixes are easier
to detect (instead of ignored), but I think if you rename the function
kstrtoull_unit_suffix() then it should be pretty clear what's supported.
> The limitation of providing both upper and lower case is due to the fact
> that we don't have a case insensitive version of strchr().
> But I think it's not that to fix, just convert them all to lower or
> upper case, then do the strchr().
>
> Would accepting both cases for the suffixes be good enough?
I think so.
Cheers, David
next prev parent reply other threads:[~2023-12-19 3:17 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-15 8:39 [PATCH 0/2] lib/kstrtox: introduce kstrtoull_suffix() helper Qu Wenruo
2023-12-15 8:39 ` [PATCH 1/2] lib/strtox: " Qu Wenruo
2023-12-18 12:59 ` David Disseldorp
2023-12-18 19:52 ` Qu Wenruo
2023-12-19 3:17 ` David Disseldorp [this message]
2023-12-19 16:42 ` David Laight
2023-12-19 21:17 ` Qu Wenruo
2023-12-20 8:31 ` David Laight
2023-12-20 9:32 ` Qu Wenruo
2023-12-15 8:39 ` [PATCH 2/2] btrfs: sysfs: use kstrtoull_suffix() to replace memparse() Qu Wenruo
2023-12-18 7:49 ` David Disseldorp
2023-12-18 8:11 ` Qu Wenruo
-- strict thread matches above, loose matches on Subject: below --
2023-12-18 13:44 [PATCH 1/2] lib/strtox: introduce kstrtoull_suffix() helper Andy Shevchenko
2023-12-20 9:54 Alexey Dobriyan
2023-12-20 10:01 ` Qu Wenruo
2023-12-20 14:16 ` Andy Shevchenko
2023-12-20 14:24 Andy Shevchenko
2023-12-20 20:38 ` Qu Wenruo
2023-12-21 12:00 ` Andy Shevchenko
2023-12-21 20:37 ` Qu Wenruo
2023-12-21 20:55 ` Andy Shevchenko
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=20231219141726.5c1e01bd@echidna \
--to=ddiss@suse.de \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=christophe.jaillet@wanadoo.fr \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
--cc=wqu@suse.com \
/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.