coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: numfmt enhancements to emulate df -g


From: Pádraig Brady
Subject: Re: numfmt enhancements to emulate df -g
Date: Fri, 19 Jun 2015 22:29:39 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]