Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Paul Eggert]

address@hidden (Richard Kenner) writes:

> that one is a weak example because it's *much* more likely that
> the author of that code didn't even *think* about the INT_MIN case

I think this seriously underestimates the programming abilities of the
original Unix developers.  But if that example doesn't convince you,
how about this one, taken from the Unix v7 /usr/src/libc/gen/rand.c:

        static  long    randx = 1;
        ...
        rand()
        {
                return(((randx = randx*1103515245 + 12345)>>16) & 077777);
        }

Surely here the programmer knew and expected wrapv semantics.

Almost exactly same 'rand' code lives on in Solaris.  OpenSolaris
/usr/src/ucblib/libucb/port/gen/rand.c (2006-11-21) has this:

        static  int     randx = 1;
        ...
        int
        rand(void)
        {
                return ((randx = randx * 1103515245 + 12345) & 0x7fffffff);
        }

Again, the wrapv assumption is clearly there.

GCC won't break this code now, but GCC is entitled to break it because
the code violates the strict C99 standard.  A simple and plausible
optimization that would break the Solaris code, for example, would be
to omit the "& 0x7fffffff" because randx must always be positive when
behavior is well-defined.

I am sure I can come up with many other examples.  The wrapv
assumption was and is pervasive in real-world Unix code.

>> Wait, though: K&Rv2 is post-C89.  
>
> Not completely: it's published in 1988, but the cover says "based on
> draft-proposed ANSI C".

Yes, I should have been more precise and written "intended to be
post-C89".  Whichever way it's said, though, K&Rv2 is not the best
source for documenting traditional C semantics.

> the *purpose* of the original ANSI C standard was to standardize common
> practice in C precisely because people were already writing in a language
> that went beyond K&R so there was need to precisely define that language.

Sure, but as with any standard, there were multiple cross-currents of
purpose.  One strong influence on the C89 standard was that of
compiler writers, who wanted to place enough constraints on the
standard that they could do Fortran-style optimizations on C code.

I don't think the _users_ of C had much to say about the treatment of
integer overflow in C89.  As is usual in standardization battles like
this, users generally are poorly represented in the relevant
committees and their concerns are reflected only indirectly in the
standard.  Typically, the most that users can do is vote with their
feet afterwards.

> I just found the Rationale document for ANSI C (C89).  In the section on
> Additive Operators, it says "Overflow was considered not to break old code
> since it was undefined by K&R".

If memory serves K&Rv1 didn't talk about overflow, yes.