Re: [groff] 1.22.4.rc4 - Final RC before official 1.22.4

[Ingo Schwarze]

Hi Deri, hi Bertrand,

i found out more about why the mom test is failing on Solaris 11.
It turns out not just the test is broken, but there is likely a
portability issue in gropdf(1).

I see this in the build log:

    GROFF    contrib/mom/examples/typesetting.pdf
  Negative length at /home/schwarze/groff-1.22.4.rc4p1.solaris11/build/gropdf
                  line 2430.
    GROFF    contrib/mom/examples/slide-demo.pdf

Comparing the resulting file typesetting.pdf to the correct version built
on Linux, it turns out the version built on Solaris 11 is truncated.
It looks like gropdf(1) simply dies half-way through processing the
file with the above fatal error message printed by the Perl interpreter.

Here is the beginning of the text that is missing from the outpiut file:

  24 0 obj << /Contents [25 0 R  ]
  /Group << /CS /DeviceRGB
  /S /Transparency
  >>
  /MediaBox [0 0 612 792 ]
  /Parent 2 0 R
  /Type /Page
  >>
  endobj
  25 0 obj << /Filter /FlateDecode
  /Length 4239
  >>
  stream
  [...]

 $ wc typesetting.pdf.*     
    2191   16414  504021 typesetting.pdf.linux
      29     126    3566 typesetting.pdf.solaris

Line 2430 in gropdf.pl is:

                my $chk=read($F,$data,$sl);

so apparently

                my $sl=unpack('L',$hdr);

yields a number so large that it wraps around to negative
when passed to read(3p).

So i surrounded the suspicious unpack() call with debugging
output as follows:

        printf STDERR "hdr: %d %d %d %d\n",
            ord($hdr), ord(substr $hdr, 1),
            ord(substr $hdr, 2), ord(substr $hdr, 3);
        my $sl=unpack('L',$hdr);
        print STDERR "sl: $sl\n";

The output is:

    GROFF    contrib/mom/examples/typesetting.pdf
  hdr: 176 6 0 0
  sl: 2953183232
  Negative length at /home/schwarze/groff-1.22.4.rc4p1.solaris11/build/gropdf
                  line 2435.
    GROFF    contrib/mom/examples/slide-demo.pdf

I guess the length is supposed to be 176 + 2 * 256 = 688 (little endian)
but is instead calculated as 176 * 256^3 + 6 * 256^2 = 2953183232
(big endian).

Frankly, that looks like an endianness bug.  Did anybody ever test
gropdf(1) on a big-endian platform?

Not sure what to do about it, though, since i don't really understand
the code in the GetChunk() function...

Yours,
  Ingo