[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ingo Schwarze
Subject: Re: [groff] 1.22.4.rc4 - Final RC before official 1.22.4
Date: Fri, 7 Dec 2018 02:41:54 +0100
User-agent: Mutt/1.8.0 (2017-02-23)

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

address@hidden:~/groff-1.22.4.rc4p1.solaris11/build > make check
make  check-am
make  all-am
make  check-TESTS
PASS: contrib/gdiffmk/tests/
PASS: contrib/hdtbl/examples/
sed -e "s|address@hidden@]|/home/schwarze/groff-1.22.4.rc4p1.solaris11/build|g" 
            -e "s|address@hidden@]|yes|g" \
        ../contrib/mom/examples/ > 
chmod +x contrib/mom/examples/
PASS: contrib/mom/examples/
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

> 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";'

address@hidden > perl -MConfig -e 'print "$Config{byteorder}\n";'

> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]