HelloPádraig,
Regarding the failing 'numfmt':
On 06/28/2015 04:20 PM, Assaf Gordon wrote:
Sadly numfmt fails on all of them, with something like this:
$ ./src/numfmt --to=si 4000
0K
<...>
Which hints the problem is in numfmt.c:797, perhaps the system's "snprintf" can't handle the format
"%.*Lf" correctly with "long double" ?
This is a long shot, but I'd thought I'll ask anyway:
In this commit:
http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=0a279f619055cc165bb3cfa3bb737cdd28ed4d70
The diff is:
===
- stpcpy (pfmt, show_decimal_point ? ".1Lf%s" : ".0Lf%s");
+ stpcpy (pfmt, ".*Lf%s");
+
+ int prec = user_precision == -1 ? show_decimal_point : user_precision;
/* buf_size - 1 used here to ensure place for possible scale_IEC_I suffix. */
- num_size = snprintf (buf, buf_size - 1, fmt, val, suffix_power_char (power));
+ num_size = snprintf (buf, buf_size - 1, fmt, val, prec,
+ suffix_power_char (power));
===
which switches from fixed-length format (".1Lf") to variable length format
(".*Lf"),
and adds the variable "prec" to "snprintf".
Could it be that "prec" should come before "val" in the parameters?
If I test it with:
long double d;
int prec;
snprintf(buf,sizeof(buf),"%.*Lf\n",d,prec);
There's a compiler warning about incorrect types to snprintf.
There's no warning in numfmt because the format string is not hard-coded but
stored in variable 'fmt'.
WDYT?
thanks,
- assaf
