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 v3 2/4] kstrtox: introduce a safer version of memparse()
Date: Thu, 4 Jan 2024 17:25:50 +1030 [thread overview]
Message-ID: <1dbb1cd1-15fa-401f-8356-474c85a46f3b@gmx.com> (raw)
In-Reply-To: <bd4f25a9-9584-42bc-bde8-b9ca82cbc1c5@infradead.org>
On 2024/1/4 17:20, Randy Dunlap wrote:
>
>
> On 1/3/24 22:42, Qu Wenruo wrote:
>>
>>
>> On 2024/1/4 17:00, Randy Dunlap wrote:
>>> Hi,
>>>
>> [...]
>>>> + * parameter.
>>>> + *
>>>> + * @suffixes: The suffixes which should be parsed. Use logical ORed
>>>> + * memparse_suffix enum to indicate the supported suffixes.
>>>> + * The suffixes are case-insensive, all 2 ^ 10 based.
>>>
>>> case-insensitive
>>>
>>>> + * Supported ones are "KMGPTE".
>>>> + * NOTE: If one suffix out of the supported one is hit, it would
>>>
>>> ones
>>>
>>>> + * end the parse normally, with @retptr pointed to the unsupported
>>>> + * suffix.
>>>
>>> Could you explain (or give an example) of "to the unsupported suffix"?
>>> This isn't clear IMO.
>>
>> Oh, my bad, that sentence itself is not correct.
>>
>> What I really want to say is:
>>
>> If one suffix (one of "KMGPTE") is hit but that suffix is not
>> specified in the @suffxies parameter, it would end the parse normally,
>> with @retptr pointed to the (unsupported) suffix.
>
> (corrected ^^^)
>
>> The example would be the "68k " case in the ok cases in the next patch.
>> We have two different cases for the same "68k" string, with different
>> @suffixes and different results:
>>
>> "68k ", KMGPTE -> 68 * 1024, @retptr at " ".
>> "68k ", M -> 68, @retptr at 'k'.
>>
>> I don't have a better expression here unfortunately, maybe the special
>> case is not even worthy explaining?
>>
>
> No, the corrected paragraph above is good. (s/would end/ends/)
>
> Except for one thing: the examples here terminate on a space character,
> but the function kernel-doc says "null-terminated":
Oh, all the strings used here and in the test cases are all "\0" ended.
Just to make it a little more readable (and easier to type), the tailing
"\0" is not explicitly showed.
That extra ' ' in the "68k \0" case is just to make sure the @retptr is
properly updated.
For all the other existing ok cases for memparse_safe() (those without
extra tailing chars), the @retptr points to the tailing NUL '\0'.
Thanks,
Qu
>
> +/**
> + * memparse_safe - convert a string to an unsigned long long, safer version of
> + * memparse()
> + *
> + * @s: The start of the string. Must be null-terminated.
>
>
>
>
>>>
>>>> + *
>>>> + * @res: Where to write the result.
>>>> + *
>>>> + * @retptr: (output) Optional pointer to the next char after parse completes.
>>>> + *
>>>> + * Return 0 if any valid numberic string can be parsed, and @retptr updated.
>>>> + * Return -INVALID if no valid number string can be found.
>>>> + * Return -ERANGE if the number overflows.
>>>> + * For minus return values, @retptr would not be updated.
>>>
>>> * 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.
>>>
>>>
>>> For *ALL* of the comments, I request/suggest that you change the "would be" or
>>> "would not be" to "is" or "is not" or whatever present tense words make the
>>> most sense.
>>
>> No problem.
>
>
next prev parent reply other threads:[~2024-01-04 6:56 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-03 23:27 [PATCH v3 0/4] kstrtox: introduce memparse_safe() Qu Wenruo
2024-01-03 23:27 ` [PATCH v3 1/4] kstrtox: always skip the leading "0x" even if no more valid chars Qu Wenruo
2024-01-03 23:27 ` [PATCH v3 2/4] kstrtox: introduce a safer version of memparse() Qu Wenruo
2024-01-04 6:30 ` Randy Dunlap
2024-01-04 6:42 ` Qu Wenruo
2024-01-04 6:50 ` Randy Dunlap
2024-01-04 6:55 ` Qu Wenruo [this message]
2024-01-03 23:27 ` [PATCH v3 3/4] kstrtox: add unit tests for memparse_safe() Qu Wenruo
2024-01-03 23:27 ` [PATCH v3 4/4] btrfs: migrate to the newer memparse_safe() helper Qu Wenruo
2024-01-06 14:34 ` [PATCH v3 0/4] kstrtox: introduce memparse_safe() Andy Shevchenko
2024-01-06 20:58 ` Qu Wenruo
2024-01-14 13:42 ` Andy Shevchenko
2024-01-14 20:01 ` Qu Wenruo
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=1dbb1cd1-15fa-401f-8356-474c85a46f3b@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