[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Richard Kenner
Subject: Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
Date: Sun, 31 Dec 2006 08:20:10 EST

> Wait, though: K&Rv2 is post-C89.  

Not completely: it's published in 1988, but the cover says "based on
draft-proposed ANSI C".

> Naturally K&Rv2 documents this, but if you want to know about
> traditional practice the relevant wording should come from K&Rv1,
> not v2.
> I don't know what K&Rv1 says on the subject, 

I think it's silent on the subject, but that's really old memory on my part.
Remember that this was in an era before most people were used to thinking
seriously about language semantics and thing that we now call "implementation
defined" and "undefined" weren't thought about.  Certainly within that
community, practical issues were more important than any concept of

> but from other evidence it's clear that common traditional practice assumes
> wrapv semantics.

"Common traditional C" was actually yet another language that was even more
ill-defined because it included such things as structure assignment that
weren't in K&Rv1.

> I just now looked at the implementation of atoi() in
> 7th Edition Unix, which is about as traditional as it gets.  It
> ends as follows:
>       while(*p >= '0' && *p <= '9')
>               n = n*10 + *p++ - '0';
>       return(f? -n: n);
> where p is char* and n is int.  This relies on wrapv semantics
> when atoi returns INT_MIN.  I'm sure many similar examples can be
> found in the V7 sources.

Maybe, but 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 rather
than made a conscious decision to depend on wrapping semantics in that case.
In that era, thinking about boundary conditions was also rare.  So, for all
we know, this might have been considered a bug even by the original author.

The counter-argument your arguments about common practice at the time is that
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.

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".  The discussion of "elimination of the
regrouping rule" talks about "implementations with twos-complement arithmetic
and silent wraparound on overflow" and then in the next sentence "any
implementation".  This seems to imply that both types of implementations
existed in the mid-80's.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]