From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109041 invoked by alias); 6 Oct 2016 16:52:59 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 109029 invoked by uid 89); 6 Oct 2016 16:52:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.6 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=argue, sum, wish X-HELO: mx1.redhat.com From: DJ Delorie To: Paul Eggert Cc: carlos@redhat.com, libc-alpha@sourceware.org Subject: Re: [PATCH] [BZ 20628] make mallinfo saturating In-Reply-To: <9b2ad307-2db2-c270-a4b9-97ca87e5208f@cs.ucla.edu> (message from Paul Eggert on Wed, 5 Oct 2016 23:34:07 -0700) Date: Thu, 06 Oct 2016 16:52:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2016-10/txt/msg00140.txt.bz2 Paul Eggert writes: > I don't see how that follows. If INTERNAL_SIZE_T and int are both 32 > bits, then (INTERNAL_SIZE_T)(SUM) + (INTERNAL_SIZE_T)(ADD) is a 32-bit > unsigned addition. This addition can overflow and wrap around, but > the code doesn't check for that overflow. I'm not arguing that the logic handles it, I'm arguing that with a 32-bit memory space none of the values will "happen" to cause an overflow, because we never have more than 2^32 bytes of memory or 2^32 objects to count. I.e. overflow would only happen in the case where the logic handles it properly. I'll add a comment to this effect, unless you're arguing that the macro should be more general-purpose, which we can argue in an independent context if you wish. >>> Also, if SUM is INT_MIN >> >> "Assumes ADD and SUM are positive." > > That assumption is incorrect, since SUM can be INT_MIN after a > wraparound overflow. Well it *used* to be correct... /me will work on that ;-)