From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Randy Dunlap <rdunlap@infradead.org>, Qu Wenruo <wqu@suse.com>,
linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org, christophe.jaillet@wanadoo.fr,
andriy.shevchenko@linux.intel.com, David.Laight@ACULAB.COM,
ddiss@suse.de, geert@linux-m68k.org
Subject: Re: [PATCH v4 2/4] kstrtox: introduce a safer version of memparse()
Date: Mon, 15 Jan 2024 15:57:15 +1030 [thread overview]
Message-ID: <848c719c-daa2-403a-b7eb-f172b4236dc1@gmx.com> (raw)
In-Reply-To: <64def21a-2727-455b-9e35-e2a56d2f1625@infradead.org>
On 2024/1/15 14:57, Randy Dunlap wrote:
[...]
>> @@ -113,6 +113,105 @@ static int _kstrtoull(const char *s, unsigned int base, unsigned long long *res)
>> return 0;
>> }
>>
>> +/**
>> + * memparse_safe - convert a string to an unsigned long long, safer version of
>> + * memparse()
>> + *
>> + * @s: The start of the string. Must be null-terminated.
>
> Unless I misunderstand, this is the biggest problem that I see with
> memparse_safe(): "Must be null-terminated".
> memparse() does not have that requirement.
This is just an extra safety requirement.
In reality, memparse_safe() would end at the either the first
unsupported suffix after the valid numeric string (including '\0'),
or won't be updated if any error is hit (either no valid string at all,
or some overflow happened).
For most if not all call sites, the string passed in is already
null-terminated.
>
> And how is @retptr updated if the string is null-terminated?
E.g "123456G\0", in this case if suffix "G" is allowed, then @retptr
would be updated to '\0'.
Or another example "123456\0", @retptr would still be updated to '\0'.
>
> If the "Must be null-terminated." is correct, it requires that every user/caller
> first determine the end of the number (how? space and/or any special character
> or any alphabetic character that is not in KMGTPE? Then save that ending char,
> change it to NUL, call memparse_safe(), then restore the saved char?
There are already test cases like "86k \0" (note all strings in the test
case is all null terminated), which would lead to a success parse, with
@retptr updated to ' ' (if suffix K is specified) or 'k' (if suffix K is
not specified).
So the behavior is still the same.
It may be my expression too confusing.
Any recommendation for the comments?
Thanks,
Qu
>
> I'm hoping that the documentation is not correct...
>
>> + * The base is determined automatically, if it starts with "0x"
>> + * the base is 16, if it starts with "0" the base is 8, otherwise
>> + * the base is 10.
>> + * After a valid number string, there can be at most one
>> + * case-insensitive suffix character, specified by the @suffixes
>> + * parameter.
>> + *
>> + * @suffixes: The suffixes which should be handled. Use logical ORed
>> + * memparse_suffix enum to indicate the supported suffixes.
>> + * The suffixes are case-insensitive, all 2 ^ 10 based.
>> + * Supported ones are "KMGPTE".
>> + * If one suffix (one of "KMGPTE") is hit but that suffix is
>> + * not specified in the @suffxies parameter, it ends the parse
>> + * normally, with @retptr pointed to the (unsupported) suffix.
>> + * E.g. "68k" with suffxies "M" returns 68 decimal, @retptr
>> + * updated to 'k'.
>> + *
>> + * @res: Where to write the result.
>> + *
>> + * @retptr: (output) Optional pointer to the next char after parse completes.
>> + *
>> + * Returns:
>> + * * %0 if any valid numeric string can be parsed, and @retptr is updated.
>> + * * %-EINVAL if no valid number string can be found.
>> + * * %-ERANGE if the number overflows.
>> + * * For negative return values, @retptr is not updated.
>> + */
>> +noinline int memparse_safe(const char *s, enum memparse_suffix suffixes,
>> + unsigned long long *res, char **retptr)
>> +{
>
> Thanks.
next prev parent reply other threads:[~2024-01-15 5:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-05 2:34 [PATCH v4 0/4] kstrtox: introduce memparse_safe() Qu Wenruo
2024-01-05 2:34 ` [PATCH v4 1/4] kstrtox: always skip the leading "0x" even if no more valid chars Qu Wenruo
2024-01-05 2:35 ` [PATCH v4 2/4] kstrtox: introduce a safer version of memparse() Qu Wenruo
2024-01-15 4:27 ` Randy Dunlap
2024-01-15 5:27 ` Qu Wenruo [this message]
2024-01-18 17:52 ` Randy Dunlap
2024-01-05 2:35 ` [PATCH v4 3/4] kstrtox: add unit tests for memparse_safe() Qu Wenruo
2024-01-05 2:35 ` [PATCH v4 4/4] btrfs: migrate to the newer memparse_safe() helper Qu Wenruo
2024-01-05 19:04 ` David Sterba
2024-01-06 14:35 ` [PATCH v4 0/4] kstrtox: introduce memparse_safe() 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=848c719c-daa2-403a-b7eb-f172b4236dc1@gmx.com \
--to=quwenruo.btrfs@gmx.com \
--cc=David.Laight@ACULAB.COM \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=christophe.jaillet@wanadoo.fr \
--cc=ddiss@suse.de \
--cc=geert@linux-m68k.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@infradead.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®