bug#8545: issues with recent doprnt-related changes

[Paul Eggert]

On 04/29/11 05:28, Richard Stallman wrote:

> We are concerned with standards insofar as they matter in practice
> for the convenience and reliability of our software.

Yes, of course, I should have made that clearer.  Standards are our
tools, not our masters.

>> If you assign i = INT_MAX + 1, the resulting behavior is undefined.
>
> The result is INT_MIN.  We don't try to support any theoretical machine
> where this would not be so.

Those machines used to be theoretical, but they're in common
use now.  Practical C code can no longer assume that integers
always wrap around when doing integer arithmetic.  For example:

   long
   foo (char *p, int i)
   {
     return &p[i + 1] - &p[i];
   }

On typical hosts where int is 32 bits, and long and char * are
both 64 bits, most compilers optimize that "return" statement
to "return 1;", even when I is INT_MAX and I + 1 therefore
overflows.  These compilers are therefore rejecting the notion
that INT_MAX + 1 must always equal INT_MIN.

Although FOO is contrived, a lot of complicated code in Emacs
mixes int and long and pointer arithmetic, and it's inevitable
that compilers are doing optimizations like the above when they
compile Emacs.  We cannot simply declare that INT_MAX + 1 must
always be INT_MIN, because that's not how compilers actually
work these days.

What we need is good advice for programmers in this area, so
that they can write C code that is portable in practice.  This
advice shouldn't be too conservative, because that would
discourage useful programs.  Nor should it be too
loosey-goosey, because that would encourage buggy programs.
Nor should it be complicated, because that would confuse
people and waste their time.  It is not easy to come up with
advice that satisfies all three constraints.