git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Barkalow <barkalow@iabervon.org>
To: Florian Weimer <fw@deneb.enyo.de>
Cc: git@vger.kernel.org
Subject: Re: [RFH] gcc constant expression warning...
Date: Sun, 28 Oct 2007 12:28:59 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0710281204350.7345@iabervon.org> (raw)
In-Reply-To: <87ir4rletv.fsf@mid.deneb.enyo.de>

On Sun, 28 Oct 2007, Florian Weimer wrote:

> * Junio C. Hamano:
> 
> > The offending lines are:
> >
> >         if (idx_size != min_size) {
> >                 /* make sure we can deal with large pack offsets */
> >                 off_t x = 0x7fffffffUL, y = 0xffffffffUL;
> >                 if (x > (x + 1) || y > (y + 1)) {
> >                         munmap(idx_map, idx_size);
> 
> x and y must be unsigned for this test to work (signed overflow is
> undefined).

I believe the test is trying to determine if signed addition on numbers of 
a certain size is safe in this environment. Doing the test with unsigned 
variables would cause the test to give a predictable but irrelevant 
result. I think gcc is being annoying in assuming that signed overflow 
doesn't occur (even when it must), rather than assuming that the result of 
signed overflow is some arbitrary and likely not useful value. If we have 
an overflow possible with off_t in the way we'd use it, then one of those 
tests should be automatically true due to the limited size of the type 
(except that I think the test should be >= instead of >). I think we 
should be able to assume that the result of a signed overflow, whatever 
undefined value it is, is a possible value of its type and therefore not 
more than the maximum value of its type, but gcc may be screwing this up.

It's probably best just to test the size of off_t.

	-Daniel
*This .sig left intentionally blank*

  reply	other threads:[~2007-10-28 16:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-28  8:46 [RFH] gcc constant expression warning Junio C Hamano
2007-10-28 10:21 ` Florian Weimer
2007-10-28 16:28   ` Daniel Barkalow [this message]
2007-10-28 10:37 ` Antti-Juhani Kaijanaho
2007-10-28 17:09   ` Linus Torvalds
2007-10-29  0:55     ` Nicolas Pitre
2007-10-29  2:41       ` Stephen Rothwell
2007-10-29  4:37       ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0710281204350.7345@iabervon.org \
    --to=barkalow@iabervon.org \
    --cc=fw@deneb.enyo.de \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).