Eric Blake <ebl...@redhat.com> writes:
> On 02/14/2017 04:26 AM, Markus Armbruster wrote:
>> To parse numbers with metric suffixes, we use
>>
>> qemu_strtosz_suffix_unit(nptr, &eptr, QEMU_STRTOSZ_DEFSUFFIX_B, 1000)
>>
>> Capture this in a new function for legibility:
>>
>> qemu_strtosz_metric(nptr, &eptr)
>>
>> Replace test_qemu_strtosz_suffix_unit() by test_qemu_strtosz_metric().
>>
>> Rename qemu_strtosz_suffix_unit() to do_strtosz() and give it internal
>> linkage.
>
> I don't know if you do this later, but coreutils (via gnulib) has a nice
> convention that:
>
> 1k => 1024
> 1kB => 1000
> 1kiB => 1024
>
> where the suffix can be used to express metric or power-of-two, letting
> the user choose which scale they want rather than hard-coding the scale.
Could be done for the calls that currently pass 1024, because the
existing one-character suffixes keep their meaning there. Would be an
incompatible change for the calls that pass 1000. There's just one
outside of tests, and it's a frequency value, i.e. 'k' makes sense, but
'kB' and 'kiB' do not.
> But implementing that is beyond this scope of this particular patch.
Indeed.
>> Signed-off-by: Markus Armbruster <arm...@redhat.com>
>> ---
>
>> @@ -251,7 +251,7 @@ fail:
>> int64_t qemu_strtosz_suffix(const char *nptr, char **end,
>> const char default_suffix)
>> {
>> - return qemu_strtosz_suffix_unit(nptr, end, default_suffix, 1024);
>> + return do_strtosz(nptr, end, default_suffix, 1024);
>> }
>>
>> int64_t qemu_strtosz(const char *nptr, char **end)
>> @@ -259,6 +259,11 @@ int64_t qemu_strtosz(const char *nptr, char **end)
>> return qemu_strtosz_suffix(nptr, end, QEMU_STRTOSZ_DEFSUFFIX_MB);
>
> Do you also want to convert this one to do_strtosz() to avoid
> double-forwarding?
See next patch :)
> Either way,
>
> Reviewed-by: Eric Blake <ebl...@redhat.com>
Thanks!
