git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/2] config: properly range-check integer values
Date: Tue, 20 Aug 2013 22:55:04 -0400	[thread overview]
Message-ID: <20130821025503.GC25296@sigill.intra.peff.net> (raw)
In-Reply-To: <20130820230749.GM4110@google.com>

On Tue, Aug 20, 2013 at 04:07:49PM -0700, Jonathan Nieder wrote:

> > I added a test. It would not fail on existing 32-bit systems, but would
> > on existing LP64 systems. It will pass with the new code on both.
> > However, it will fail on ILP64 systems (because their int is large, and
> > can represent 3GB). I'm not sure if any such systems are in wide use
> > (SPARC64?), but we would want a prereq in that case, I guess. I'm
> > inclined to wait to see if it actually fails for anybody.
> 
> Yuck.
> 
> What will go wrong if "git config --int" starts returning numbers too
> large to fit in an 'int'?  That can already happen if "git" and a
> command that uses it are built for different ABIs (e.g., ILP64 git,
> 32-bit custom tool that calls git).

I'm not sure I understand your question. "git config --int" cannot
return numbers that do not fit in an "int", since we use an int as an
intermediate representation type. The intent of the code is to
range-check the input and complain. But the code gets it wrong, and
sometimes truncates the value instead. So we continue to never show
anything that would not fit in an "int", but now our range-check
correctly complains rather than truncating in some cases.

If you are worried about a 32-bit command calling an ILP64 git, then
nothing is made worse by this patch. We return the same range of values
as before.

Short of adding "--int32", etc to git-config, I don't think git can be
responsible for this situation. It can only say "This does not fit in my
internal representation, and I would barf on it". If you do not tell it
that your int is smaller, then it cannot say "you would barf on it".

> It's possible that what the test should be checking for is "either
> returns a sane answer or fails" (which would pass regardless of ABI).
> Something like:
> 
> 	test_expect_success 'large integers do not confuse config --int' '
> 		git config giga.crash 3g &&
> 		test_might_fail git config --int giga.crash >actual &&
> 		echo 3221225472 >expect &&
> 		{
> 			test_cmp expect actual ||
> 			test_must_fail git config --int giga.crash
> 		}
> 	'
> 
> Sensible?

Yes, that would cover an ILP64 system, though it very much muddies the
point of the test (which is to find a value that is represented by a
long, but not an int; such a value does not exist at all on ILP64).

Which is why I wondered about avoiding it with a prerequisite.

-Peff

  reply	other threads:[~2013-08-21  2:55 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-20 22:39 [PATCH 0/2] git-config and large integers Jeff King
2013-08-20 22:42 ` [PATCH 1/2] config: properly range-check integer values Jeff King
2013-08-20 23:07   ` Jonathan Nieder
2013-08-21  2:55     ` Jeff King [this message]
2013-08-20 22:44 ` [PATCH 0/2] git-config and large integers Stefan Beller
2013-08-20 22:48   ` Jeff King
2013-08-20 22:47 ` [PATCH 2/2] teach git-config to output " Jeff King
2013-08-20 22:57   ` Jonathan Nieder
2013-08-21  3:00     ` Jeff King
2013-08-21  4:38       ` Jonathan Nieder
2013-08-21  5:00         ` Jeff King
2013-08-21  6:34           ` Jonathan Nieder
2013-08-20 23:06 ` [PATCH 0/2] git-config and " Junio C Hamano
2013-08-20 23:41   ` Junio C Hamano
2013-08-21  2:43     ` Jeff King
2013-08-21  2:34   ` Jeff King
2013-09-08  8:27 ` [PATCHv2 0/5] " Jeff King
2013-09-08  8:29   ` [PATCH 1/5] config: factor out integer parsing from range checks Jeff King
2013-09-08  8:33   ` [PATCH 2/5] config: properly range-check integer values Jeff King
2013-09-08  8:36   ` [PATCH 3/5] config: set errno in numeric git_parse_* functions Jeff King
2013-09-09  0:36     ` Eric Sunshine
2013-09-09 19:53       ` Jeff King
2013-09-08  8:38   ` [PATCH 4/5] config: make numeric parsing errors more clear Jeff King
2013-09-08  8:40   ` [PATCH 5/5] git-config: always treat --int as 64-bit internally Jeff King
2013-09-09 18:58   ` [PATCHv2 0/5] git-config and large integers Junio C Hamano

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=20130821025503.GC25296@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).