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

[Paul Eggert <eggert@cs.ucla.edu>]

On 04/07/2011 11:31 AM, Eli Zaretskii wrote:
> `doprnt' was careful in these cases, e.g., it would take care of truncating
> multibyte strings only on character boundaries.

Thanks for the review.  This problem should be OK, as the only place
where truncation can occur is in the call from vmessage to doprnt,
and the patched arranges for vmessage to do that truncation.

> It also supported %c format for converting a multibyte character to
> its integer representation.

This problem should be OK too.  I manually inspected all the places
that used the %c format.  All but one of them used %c only to convert
unibyte characters, so they're OK.  The only exception was in
charset_iso_charset_parameter, and I modified that function to convert
the multibyte character before passing it as a string to 'error'.

> There's also an issue with old pre-C99 implementations of `vsnprintf'
> which returned -1 when the buffer was too small.  However, I think
> catering for those would be a trivial change in `verror', so that's
> not a big deal.

Yes, thanks, I'll look into this.

Another issue has come up in further static analysis.  The vsnprintf
API does not work for strings longer than INT_MAX bytes.  For
vmessage's use of vsnprintf this is OK, since (for other reasons) a
frame title can't be that long.  However, for verror this is an
arbitrary limitation on typical 64-bit hosts.  I'll look into this,
and plan to propose a further patch to handle it.  Gnulib already
handles this situation, with its vasnprintf module, and most likely
I'll end up using that, or a variant of that.  This will most likely
affect the Windows port too.