On 2/5/21 5:10 AM, Daniel P. Berrangé 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. > > I don't think we should be deprecating this, as I think it makes > it very user hostile. Users who require exact answers, won't be > using fractional syntax in the first place. IOW, by using fractional > syntax you've decided that approximation is acceptable. Given that, > I should not have to worry about whether or not the fraction I'm > using is exact or truncated. It is horrible usability to say that > "1.1k" is invalid, while "1.5k" is valid - both are valid from my > POV as a user of this. > > > >> 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. > > This is only an warning, so setting an Err ** would not be appropriate > right now. > > None the less we should add an Err **, because many of the callers > want an Err ** object populated, or use error_report().
That is more effort. What's the consensus - is it important enough that I should spend that effort getting rid of technical debt by adding versions of qemu_strto* that take Err** at this point in time? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org