Re: new snapshot available: coreutils-8.23.237-eff51 - OpenSolaris failures (numfmt)

[Assaf Gordon]

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