From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8189 invoked by alias); 11 Jul 2005 17:04:29 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 8174 invoked by uid 22791); 11 Jul 2005 17:04:25 -0000 Received: from host217-40-213-68.in-addr.btopenworld.com (HELO SERRANO.CAM.ARTIMI.COM) (217.40.213.68) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 11 Jul 2005 17:04:25 +0000 Received: from mace ([192.168.1.25]) by SERRANO.CAM.ARTIMI.COM with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 18:03:52 +0100 From: "Dave Korn" To: "'Nicholas Nethercote'" , "'Nathan Sidwell'" , "'Paul Brook'" Cc: Subject: RE: Where does the C standard describe overflow of signed integers? Date: Mon, 11 Jul 2005 17:04:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In-Reply-To: Message-ID: X-SW-Source: 2005-07/txt/msg00434.txt.bz2 ----Original Message---- >From: Nicholas Nethercote >Sent: 11 July 2005 17:08 > On Mon, 11 Jul 2005, Dave Korn wrote: > >>> There was recently a very long thread about the overflow behaviour of >>> signed integers in C. Apparently this is undefined according to the C >>> standard. I searched the standard on this matter, and while I did find >>> some paragraphs that described how unsigned integers must wrap around >>> upon overflow, I couldn't find anything explicit about signed integers. Mangled attribution there, I didn't say that, you did! There's no reason to leave in the "So-and-so wrote" line if you haven't quoted a single word of what so-and-so actually wrote.... > The difference between signed and unsigned integer overflow is a little > unclearly expressed, I think. > > 3.4.3/3 says: > > "EXAMPLE An example of undefined behavior is the behavior on integer > overflow" > > 6.5/5 says: > > "If an _exceptional condition_ occurs during the evaluation of an > expression (that is, if the result is not mathematically defined or > not in the range of representable values for its type), the behavior > is undefined." > > These two paragraphs would seem to indicate that overflow is undefined for > both signed and unsigned integers. Not quite; you have to read all the implications at once. 3.4.3/3 says that the behaviour "on integer overflow" is undefined, but because it elsewhere says that unsigned ints don't overflow, that para only applies to signed ints. Likewise, because unsigned ints are defined to use modulo arithmetic, no "exception condition" occurs, because the result _is_ defined and the modulo rule keeps it within the "range of representable values for its type". > But then 6.2.5 para 9, sentence 2 says: > > "A computation involving unsigned operands can never overflow, because > a result that cannot be represented by the resulting unsigned integer > type is reduced modulo the number that is one greater than the largest > value that can be represented by the resulting type." > > Which requires that unsigned ints must wrap on overflow. (Actually, I > guess it defines "overflow" such that unsigned ints never "overflow", so > 3.4.3/3 and 6.5/5 don't apply!) > > But I think the paragraphs together are good enough to communicate that: > unsigned ints must wrap on overflow, signed ints need not. Thanks again > for your help. Ah, I see you've already worked out for yourself what I wrote above. Yes, the language in these standards is very hard to read, because you can't consider any individual point by itself; they don't all explicitly itemise the other points that might interact with or modify them, as you've seen, so it requires a good familiarity with the standard to know if some other part of it might make a difference to the interpretation of the bit you're examining on any given occasion. cheers, DaveK -- Can't think of a witty .sigline today....