On 28/06/15 21:51, Assaf Gordon wrote: > 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'.
Wow, good catch! I'm amazed it passes tests. I guess the overlap of the zeros in small int prec and the zeros in the reduced long double val cancel out :/ I'll apply in your name. thanks! Pádraig.
