GNU bug report logs - #73068
printf: please implement POSIX:2024 argument reordering

Previous Next

Full log

Message #31 received at 73068 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Collin Funk <collin.funk1 <at> gmail.com>,
 73068 <at> debbugs.gnu.org
Cc: bruno <at> clisp.org
Subject: Re: bug#73068: printf: please implement POSIX:2024 argument reordering
Date: Fri, 13 Sep 2024 13:55:26 +0100

[Message part 1 (text/plain, inline)]

On 12/09/2024 20:33, Paul Eggert wrote:
> On 2024-09-12 12:03, Pádraig Brady wrote:
> 
> 
>> This is tricky enough, that we should be as restrictive as possible here,
>> so I may resort to strspn(f, "0123456789") to parse instead.
>> I'll think a bit about it.
> 
> The code's also assuming INT_MAX < INTMAX_MAX, which POSIX doesn't
> require. You could put in a static_assert to that effect, I suppose, to
> document the assumption.

Indeed. We would have incorrectly taken the INTMAX_MAX arg in the
(albeit unlikely) case where INT_MAX >= INTMAX_MAX,
and the provided number overflowed INTMAX_MAX.
To be explicit, strtol() doesn't return 0 in that case,
so we need to check overflow (like Colin suggested).

> More important, though, if you're not in the C locale all bets are off
> as far as what strtoimax will also parse.
> 
> When I ran into this problem with GNU tar, I ended by giving up on
> strtoimax and did my own little integer parser. It does exactly what I
> want and I don't have to fire up the strtoimax complexity+locale engine.

Right, it's best to preparse for the above reason,
and to avoid any confusion re leading spaces etc. like I previously mentioned.

The attached adjustment does the preparse with strspn(),
and only does the strtoimax() for appropriate strings.

cheers,
Pádraig

[printf-indexed-adj2.diff (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.