Re: 14.3-RELEASE gpart show output (?.?T) vs. 14.4 and 15.0 and main: why do 14.4 and 15.0 and main have some single significant digit (?T) size figures?

On 4/19/26 10:11, Zhenlei Huang wrote:
> 
> 
>> On Apr 19, 2026, at 11:03 PM, Mark Millard <[email protected]> wrote:
>>
>> 14.3-RELEASE (more useful):
>>
>> =>        40  1875384928    da1  GPT  (894G)
>> =>        40  2930277095    nda1  GPT  (1.4T)
>> =>        34  2930277101    da0  GPT  (1.4T)
>> =>        34  3907029101    nda0  GPT  (1.8T)
>> =>        34  4000797293    nda3  GPT  (1.9T)
>>
>>
>> 14.4-RELEASE and 15.0-RELEASE and main (less useful):
>>
>> =>        40  1875384928    da1  GPT  (894G)
>> =>        40  2930277095    nda1  GPT  (1T)
>> =>        34  2930277101    da0  GPT  (1T)
>> =>        34  3907029101    nda0  GPT  (2T)
>> =>        34  4000797293    nda3  GPT  (2T)
>>
> 
> It appears to be caused by 4f809ffec69c (gpart: add libxo support for "show" subcommand + man page updates) .
> 
> Prior to the change the size was formatted to human friendly format by `fmtsize(pp->lg_mediasize))` which in turn calls 
> ```
> humanize_number(buf, sizeof(buf), rawsz, "", HN_AUTOSCALE,
>             HN_B | HN_NOSPACE | HN_DECIMAL);
> ```,
> 
> now it is formatted with 
> ```
> xo_emit("  ({h:size/%jd})\n", (intmax_t)pp->lg_mediasize);
> ```
> 
> It appears that libxo does not handle well with numbers those exceed 10^12, ( 1 Terabyte in this case ).

My guess is that a size in the Range 1.0G .. 1.4G or so would now
display (1G) and that in the range 1.5G .. 2.4G or so would display 2G
--and so on until 9.5G .. 99.4G or so shows 2 digits before the G. In
other words: it picks the G (or whatever) first without considering the
significant digits issue that results from its handling (given no
fractional part in the formatting).

But I've not tested such.

A better pick for 1.0G .. 9.4G or so would be M . One would image using
M for 1.0G .. 99.4G or so but G for 99.5G .. 999.4G or so. The notation
does not need to use fractional notation to get 2 to 3 significant
digits generally, if it picks the likes of M vs. G units appropriately
to having the significant digits as well.

(I've avoided being explicit about 1000 vs. 1024 being used for M vs. G
here.)

> 
>>
>> -- 
>> ===
>> Mark Millard
>> marklmi at yahoo.com
>>
>>
> 
> Best regards,
> Zhenlei
> 
> 
> 


-- 
===
Mark Millard
marklmi at yahoo.com