Yann POUPET wrote: >>>> DESCRIPTION >>>> The humanize_number() function will convert the signed integer >>>> <value> to a string, which will write at most <buf_len> bytes >>>> to the output <buffer>. The format of the output string >>>> is described by the <fmt> string. >>>> >>>> Conversion Specification >>>> The <fmt> string determines how <value> will be formatted to >>>> the output in a fashion similar to sprintf(). Each conversion >>>> specifier within the string consists of the % character, after >>>> which the following appear in sequence: >>>> >>>> >> Why is there no way to request that a % character be included in the >> output. >> >> >> > > Indeed ... '%%' would permit to have the '%' char to be included. > > Is there any statement as to how characters in the format string that are not part of the conversion specification will be handled? Example: humanize_number(123456789, "The number is %5M\n", buffer, len);
The sentence beginning with 'Each conversion' in the man page above, sounds like the function supports multiple conversions. Example: humanize_number(123456789, "%5M can also be %8K\n", buffer, len); Or with Carlson's proposed rewrite and the obvious extension humanize_number(buffer, len, "%5M can also be %10K\n", 123456789, 987654321); Where would the similarity to sprintf / _ndoprnt end? humanize_number(buffer, len, "%*.*M", 5, 2, 123456789); humanize_number(buffer, len, "%d %M", 5, 123456789); If this is an extension to the existing sprintf formatting, then we ought to find a way to integrate these conversions with _ndoprnt and that ought to be in the proposal. If this is strictly a numeric conversion, similar to lltostr() then I see no benefit to the leading % in the format string or even having a format string replacing NETBSD's implementation. It's going to lead to an obvious leap of faith, followed by a thud. Other random comments Finally what format string produces the following humanized number? 123,456,789
