On 19/06/15 20:08, Pádraig Brady wrote:
> Subject: [PATCH 4/4] numfmt: support user specified output precision
> diff --git a/src/numfmt.c b/src/numfmt.c
> + if (fmt[i] == '.')
> + {
> + i++;
> + errno = 0;
> + user_precision = strtol (fmt + i, &endptr, 10);
> + if (errno == ERANGE || isblank (fmt[i]) || fmt[i] == '+')
> + error (EXIT_FAILURE, 0,
> + _("invalid precision in format %s"), quote (fmt));
> + if (user_precision < 0)
> + user_precision = -1; /* Ignore as with standard printf. */
> + i = endptr - fmt;
> + }
I've changed the above to disallow negative precision actually.
That's consistent with coreutils printf(1). POSIX only defines
negative precision with the .*f form (in which case it's ignored).
In the direct form it's undefined, and glibc at least will
malform output with that direct negative form, so it's better
to disallow I think. BTW I see that bash does allow the direct
form through to glibc:
bash> printf '%.*f\n' -1 1
1.000000
bash> printf '%.-1f\n' 1
%.0-1Lf
$ env printf '%.*f\n' -1 1
1.000000
$ env printf '%.-1f\n' 1
printf: %.-: invalid conversion specification
cheers,
Pádraig.
