On Mon, 2023-05-01 at 15:35 -0400, Kent Overstreet wrote: > On Mon, May 01, 2023 at 11:13:15AM -0700, Davidlohr Bueso wrote: > > On Mon, 01 May 2023, Suren Baghdasaryan wrote: > > > > > From: Kent Overstreet <kent.overstreet@xxxxxxxxx> > > > > > > Previously, string_get_size() outputted a space between the > > > number and the units, i.e. > > > 9.88 MiB > > > > > > This changes it to > > > 9.88MiB > > > > > > which allows it to be parsed correctly by the 'sort -h' command. > > > > Wouldn't this break users that already parse it the current way? > > It's not impossible - but it's not used in very many places and we > wouldn't be printing in human-readable units if it was meant to be > parsed - it's mainly used for debug output currently. It is not used just for debug. It's used all over the kernel for printing out device sizes. The output mostly goes to the kernel print buffer, so it's anyone's guess as to what, if any, tools are parsing it, but the concern about breaking log parsers seems to be a valid one. > If someone raises a specific objection we'll do something different, > otherwise I think standardizing on what userspace tooling already > parses is a good idea. If you want to omit the space, why not simply add your own variant? A string_get_size_nospace() which would use most of the body of this one as a helper function but give its own snprintf format string at the end. It's only a couple of lines longer as a patch and has the bonus that it definitely wouldn't break anything by altering an existing output. James
