bug#8435: misuse of error ("...%d...", ...) on 64-bit hosts

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 08 Apr 2011 16:34:12 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 8435@debbugs.gnu.org
> 
> On 04/08/2011 01:58 AM, Eli Zaretskii wrote:
> 
> > So I think it would be better to fix these problems as follows:
> >   ...
> >   . Fix doprnt to avoid overflow when EMACS_INT is a 64-bit type, if
> >     it could overflow.  (I don't see such a danger, but maybe I
> >     overlook something.)
> 
> That wouldn't work, not because doprnt overflows with EMACS_INT, but
> because doprnt doesn't work with ordinary 'int': it treats all integer
> arguments as if they were EMACS_INT, and this relies on unportable
> va_arg behavior.

Then let's change doprnt to support an `int'.  With the new descriptor
you introduced for EMACS_INT, it shouldn't be a problem to leave %d
and %u for `int' data types.  Are there any problems with this
approach?

> No doubt these problems could be worked around with sufficient
> hacking, but why bother?  The main reason doprnt exists is that
> vsnprintf didn't exist back when doprnt was written, so we had to
> write it ourselves.  But now that we can rely on vsnprintf, let's use
> it rather than continuing to maintain our reinvented buggy wheel.

That would be okay if vsnprintf was a drop-in replacement.  But as we
see, it isn't: doprnt provides a few features that vsnprintf does not,
and adding that support in other places has disadvantages that I
mentioned in my previous message.  So I think we should consider also
the alternative of fixing doprnt instead.  If it proves to be
reasonably easy, I think it's preferable, since that localizes the
changes.