Hi Deri,
Deri wrote on Fri, Dec 07, 2018 at 12:09:20AM +0000:
> I only have access to intel or arm. Please can you test changing
> line 2428 to:-
>
> my $sl=unpack('L>',$hdr);
>
> I.E. Adding the ">" symbol.
With 'L>', the problem remains unchanged. I guess that is due to the
fact that the native byte order is big endian on sparc anyway.
> I have checked that "L<" works here.
And so it does on sparc:
GROFF contrib/mom/examples/typesetting.pdf
hdr: 176 6 0 0
sl: 1712
hdr: 188 189 1 0
sl: 114108
hdr: 32 2 0 0
sl: 544
hdr: 175 6 0 0
sl: 1711
hdr: 193 197 1 0
sl: 116161
hdr: 32 2 0 0
sl: 544
hdr: 170 6 0 0
sl: 1706
hdr: 188 1 2 0
sl: 131516
hdr: 32 2 0 0
sl: 544
hdr: 177 6 0 0
sl: 1713
hdr: 251 230 1 0
sl: 124667
hdr: 32 2 0 0
sl: 544
GROFF contrib/mom/examples/slide-demo.pdf
schwarze@unstable11s:~/groff-1.22.4.rc4p1.solaris11/build > make check
make check-am
make
make all-am
make check-TESTS
PASS: contrib/gdiffmk/tests/gdiffmk_tests.sh
PASS: contrib/hdtbl/examples/test-hdtbl.sh
sed -e
"s|[@]abs_top_builddir[@]|/home/schwarze/groff-1.22.4.rc4p1.solaris11/build|g" \
-e "s|[@]groff_have_urw_fonts[@]|yes|g" \
../contrib/mom/examples/test-mom.sh.in >
contrib/mom/examples/tests-mom.sh
chmod +x contrib/mom/examples/tests-mom.sh
PASS: contrib/mom/examples/tests-mom.sh
make all-am
============================================================================
Testsuite summary for GNU Troff 1.22.4
============================================================================
# TOTAL: 3
# PASS: 3
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
============================================================================
I guess what is going on here is that whatever data you are processing
is in little endian byte order. So by mere chance, your old code
happens to work on intel because that's the native byte order there,
so the right byte order for the task is used by default. On sparc,
on the other hand, it seems you have to explicitly state that you
do *not* want to use the native byte order when processing that
data.
> If this cures the error then I
> need to find a way of determining which to use.
That doesn't appear to be necessary - it looks like you don't have to
specify the byte order of the machine (the machine knows about that
anyway), but you have to specify the byte order of your *data* which
you are about to process.
> What does this produce:-
>
> perl -MConfig -e 'print "$Config{byteorder}\n";'
schwarze@unstable11s > perl -MConfig -e 'print "$Config{byteorder}\n";'
87654321
> On intel and arm I see "12345678".
>
> Please could you investigate for me
Sure, that's why i'm sending reports in the first place. :-)
Thanks a lot for looking into the matter!
I think you should commit and push the change to add the '<' before
Bertrand releases. You already tested on little endian, i tested
on big endian, and it appears to work on both.
A quick grep gives me the impression that "unpack" is used nowhere else
in the groff sources. The pack(3p) a few lines below is probably not
affected by endianness because 'H' is not a binary format.
The pack(3p) in tmac/fallbacks.tmac is probably incorrect, but that's
only a comment, so maybe we need not bother.
Can you think of any other places where numbers are converted to
or from binary (as opposed to digit-string) integer formats, in
particular embedded in binary file formats that can be used across
different archictectures? Those places could be affected by similar
issues, and not all such issues necessarily cause build failures,
some might silently yield wrong results.
Yours,
Ingo
