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:

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.

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