Re: printf octal literals

[Chet Ramey]

> On 05/05/2014 05:09 AM, Dan Douglas wrote:
> > Just a heads up on something I hadn't noticed: Bash (and dash) treat
> > octal literals in printf precision inconsistently (using glibc -- not
> > sure if it's a bug or GNUism on that end or the shell):
> 
> Umm, there's no such thing as an octal precision printf format.
> 
> > 
> >     $ bash -c 'printf "<%.010d> <%.*d>\n" 1 010 1'
> 
> POSIX is clear that %.010d is identical to %.10d; an embedded precision
> is always treated as decimal.
> 
> Meanwhile, POSIX says that %.*d is not required for the printf(1)
> utility; so this is a bash extension.  The fact that bash is treating
> "'%.*d' 010" as an octal 010 rather than a decimal is odd, but I see
> nothing that requires it to behave otherwise.

Hmmm...bash uses strtoimax to convert the precision argument into an
int to pass to printf(3), and inherits whatever default behavior the
libc strtoimax implements in the absence of an explicit base argument. 

However: bash treats integer constants as consistently as possible
across all contexts.  If a constant has a leading 0x is it hex; a
leading 0 indicates octal; and so on.  This behavior is consistent with
that philosophy.

It's what printf(3) gives you as well:

printf ("<%.*d>\n", 010, 1);

displays eight characters and a newline.  I don't see anything `odd'
about it.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/