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

[Jeff King <peff@peff.net>]

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.

-Peff