[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 3/3] utils: Deprecate inexact fractional suffix sizes

From: Eric Blake
Subject: Re: [PATCH 3/3] utils: Deprecate inexact fractional suffix sizes
Date: Fri, 5 Feb 2021 08:19:08 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0

On 2/5/21 4:34 AM, Richard W.M. Jones wrote:
> On Thu, Feb 04, 2021 at 01:07:08PM -0600, Eric Blake wrote:
>> The value '1.1k' is inexact; 1126.4 bytes is not possible, so we
>> happen to truncate it to 1126.  Our use of fractional sizes is
>> intended for convenience, but when a user specifies a fraction that is
>> not a clean translation to binary, truncating/rounding behind their
>> backs can cause confusion.  Better is to deprecate inexact values,
>> which still leaves '1.5k' as valid, but alerts the user to spell out
>> their values as a precise byte number in cases where they are
>> currently being rounded.
>> Note that values like '0.1G' in the testsuite need adjustment as a
>> result.
>> Sadly, since qemu_strtosz() does not have an Err** parameter, we
>> pollute to stderr.
> Does "deprecate" mean there's a plan to eventually remove this?  If so
> I think it should say that (in docs/system/deprecated.rst I think).

Yes (well, if we agree to the patch; Dan has already voiced concern that
we may not want 3/3 after all).  And that's why I posted a followup
message mentioning that I failed to commit that docs/ change before
sending my v1.  It will be in v2.

> I think it would be better to remove this now or in the future since
> it's a trap for users.

It's borderline - Markus has expressed a desire to remove inexact
fractions, while Dan has expressed the desire that user convenience is
important (as long as we are clear that non-fractional values are ALWAYS
exact, and that the use of a fraction is for convenience at which point
you KNOW you are risking rounding, then allowing both 1.1M and 1.5M
instead of only one of the two is nicer).

I submitted this patch because of IRC discussion, but if it is up to
just me, I'd keep 2/3 but drop 3/3 (that is, I'm happy to deprecate
0x4000M, but not happy to deprecate 0.1G, but rather merely posted the
patch to see what the fallout is because the question had been asked on

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]