From: "Ævar Arnfjörð Bjarmason" <email@example.com> To: "René Scharfe" <firstname.lastname@example.org> Cc: Jeff King <email@example.com>, Derrick Stolee <firstname.lastname@example.org>, email@example.com, Yiyuan guo <firstname.lastname@example.org> Subject: Re: [PATCH 3/5] pack-objects: clamp negative window size to 0 Date: Wed, 05 May 2021 13:53:06 +0200 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> On Tue, May 04 2021, René Scharfe wrote: > Am 03.05.21 um 16:55 schrieb Jeff King: >> On Mon, May 03, 2021 at 08:10:24AM -0400, Derrick Stolee wrote: >> >>> On 5/1/2021 10:03 AM, Jeff King wrote: >>>> A negative window size makes no sense, and the code in find_deltas() is >>>> not prepared to handle it. If you pass "-1", for example, we end up >>>> generate a 0-length array of "struct unpacked", but our loop assumes it >>>> has at least one entry in it (and we end up reading garbage memory). >>>> >>>> We could complain to the user about this, but it's more forgiving to >>>> just clamp it to 0, which means "do not find any deltas at all". The >>>> 0-case is already tested earlier in the script, so we'll make sure this >>>> does the same thing. >>> >>> This seems like a reasonable approach. It takes existing "undefined" >>> behavior and turns it into well-understood, "defined" behavior. >> >> I was on the fence on doing that, or just: >> >> if (window < 0) >> die("sorry dude, negative windows are nonsense"); >> >> So if anybody has a strong preference, I could be easily persuaded. Part >> of what led me to being forgiving was that we similarly clamp too-large >> depth values (with a warning; I didn't think it was really necessary >> here, though). > > There's another option: Mapping -1 or all negative values to the > maximum: > > if (window < 0) > window = INT_MAX; > if (depth < 0) > depth = (1 << OE_DEPTH_BITS) - 1; > > That's allows saying "gimme all you got" without knowing or being > willing to type out the exact maximum value, which may change between > versions. Not all that useful for --window, I guess. That convention > has been used elsewhere I'm sure, but can't point out a concrete > example. $arr[-1] get the last item of the array $arr in PowerShell, > though, which is kind of similar. > > Sure, you get the same effect in both cases by typing 2147483647, but > -1 is more convenient. > > Not a strong preference, but I thought it was at least worth > mentioning that particular bike shed color. :) That seems sensible to expose, but I think should really be --window=max, not --window=-1. The latter feels way too much like assuming that a user might know about C's "set all bits" semantics. The one example of such a variable I could think of is core.abbrev=no, which could arguably benefit from a core.abbrev=max synonym. Another one is *.threads, e.g. grep.threads, index.threads. We currently say that "auto" is like "max, but I can see how we'd eventually benefit from splitting those up. I sometimes run git on machines where that "auto" is 48 or whatever (I haven't benchmarked, but that's surely counter-productive). Having max != auto in that case (but still having a "max") would be nice.
next prev parent reply other threads:[~2021-05-05 11:58 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-01 14:02 [PATCH 0/5] pack-objects: better handling of negative options Jeff King 2021-05-01 14:02 ` [PATCH 1/5] t5300: modernize basic tests Jeff King 2021-05-03 5:27 ` Junio C Hamano 2021-05-03 14:53 ` Jeff King 2021-05-01 14:03 ` [PATCH 2/5] t5300: check that we produced expected number of deltas Jeff King 2021-05-01 14:03 ` [PATCH 3/5] pack-objects: clamp negative window size to 0 Jeff King 2021-05-03 12:10 ` Derrick Stolee 2021-05-03 14:55 ` Jeff King 2021-05-04 18:47 ` René Scharfe 2021-05-04 21:38 ` Jeff King 2021-05-05 11:53 ` Ævar Arnfjörð Bjarmason [this message] 2021-05-05 16:19 ` René Scharfe 2021-05-01 14:04 ` [PATCH 4/5] t5316: check behavior of pack-objects --depth=0 Jeff King 2021-05-01 14:04 ` [PATCH 5/5] pack-objects: clamp negative depth to 0 Jeff King 2021-05-03 12:11 ` Derrick Stolee
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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH 3/5] pack-objects: clamp negative window size to 0' \ /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
This is a public inbox, see mirroring instructions on how to clone and mirror all data and code used for this inbox