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

[Paul Eggert]

In the Emacs trunk, src/dispnew.c contains this:

    error ("Device %d is not a termcap terminal device", t->id);

t->id is of type 'int', but the "error" routine formats %d as if it
were of type EMACS_INT.  This works on a typical 32-bit machine, but
on a 64-bit machine these two types have different representations,
and the above call relies on undefined behavior: it might work and it
might not.

The above bug can easily be fixed by casting t->id to EMACS_INT, but
other instances of the problem are not so easy.  For example,
src/term.c has this:

    maybe_fatal (must_succeed, terminal,
                 "Screen size %dx%d is too small",
                 "Screen size %dx%d is too small",
                 FrameCols (tty), FrameRows (tty));

where FrameCols and FrameRows return 'int'.  Here, if MUST_SUCCEED is
true, maybe_fatal calls 'printf' and works; but if MUST_SUCCEED is
false, maybe_fatal calls 'error' and might not work on a 64-bit machine.

I found these bugs by code inspection, and expect that there are
others like them.  Part of the problem is that it's confusing that
'error' treats format strings differently from 'printf'.  And partly
the problem is that there is currently no reliable way to catch common
programming mistakes like this.

I plan to fix this problem systematically, as follows.

  * Provide a convenient way to format EMACS_INT values using
    printf-like functions.

  * Change 'error' and similar functions so that they use
    printf-compatible format strings, and change their callers to
    format EMACS_INT values accordingly.

  * Mark 'error'-like functions with ATTRIBUTE_FORMAT_PRINTF, so that
    we can easily find other bugs like the above.