RE: [BUG] Git 2.43.0-rc0 - t4216 unpack(Q) invalid type

>On Fri, Nov 03, 2023 at 10:50:19AM -0400, rsbecker@nexbridge.com wrote:
>> In RC0, the following tests are failing (with verbose). They look like
>> the same root cause. Unpack("Q>".... What version does git now require for perl?
>> I have v5.30.3 available, nothing more recent.
>
>The perl used in the test suite is supposed to be vanilla enough to support any
>ancient version. The perl5 Git import doesn't have version tags that go back that far,
>but the quadwords in pack/unpack go back at least to a commit from 1998.
>
>So I suspect this is not a version issue, but rather a build-time config one. The docs
>say:
>
>  Q  An unsigned quad value.
>      (Quads are available only if your system supports 64-bit integer
>      values _and_ if Perl has been compiled to support those.  Raises
>      an exception otherwise.)
>
>It would probably be possible to rewrite the use of "Q" here to grab two 32-bit
>values instead. But I'd guess that on your system it is not as simple as a shift-and-
>add to then treat them as a 64-bit value, since presumably the problem is that perl's
>ints are all strictly 32-bit.
>
>What does this script produce for you:
>
>  perl -e '
>    my $bytes = "\1\2\3\4\5\6\7\8";
>    my $q = eval { unpack("Q>", $bytes) };
>    print "Q = ", defined($q) ? $q : "($@)", "\n";
>    my ($n1, $n2) = unpack("NN", $bytes);
>    print "n1 = $n1\n";
>    print "n2 = $n2\n";
>    print "computed quad = ", ($n1 << 32) | $n2, "\n";
>  '
>
>I get:
>
>  Q = 72623859790382904
>  n1 = 16909060
>  n2 = 84281144
>  computed quad = 72623859790382904
>
>but I'm guessing you get an exception report for Q, and that the computed quad is
>probably equal to n2 (the shift of n1 goes totally off the end).
>
>We may not be without hope, though. These 64-bit values are file offsets we're
>reading from the chunk files. The format naturally uses 64-bit values here to
>accommodate arbitrarily large files. But in our tests, the offsets are all going to be
>relatively small. So our "$n1" in practice will always be 0.
>
>> This same problem also happens in t5318, t5319, t5324
>
>Yep. The offending code is in lib-chunk.sh, so the new tests added in all of those
>scripts which use it will run into the same problem.