+++ This bug was initially created as a clone of Bug #131132 +++

Description of problem:
With ncompress-4.2.4-33 and -38, we're seeing the following behavior
on zSeries:

.qa.[root@kryten jkt]# ls -l anaconda
-rwxr-xr-x    1 root     root        31093 Apr 22 16:04 anaconda
.qa.[root@kryten jkt]# file anaconda
anaconda: a /usr/bin/python2.2 script text executable
.qa.[root@kryten jkt]# compress anaconda
.qa.[root@kryten jkt]# ls -l anaconda.Z
-rwxr-xr-x    1 root     root        14955 Apr 22 16:04 anaconda.Z
.qa.[root@kryten jkt]# file anaconda.Z
anaconda.Z: compress'd data block compressed 16 bits
.qa.[root@kryten jkt]# uncompress anaconda.Z
.qa.[root@kryten jkt]# ls -l anaconda
-rwxr-xr-x    1 root     root         9586 Apr 22 16:04 anaconda
.qa.[root@kryten jkt]# file anaconda
anaconda: data

Doing a little rooting around, it actually appears that it's
"compress" which is doing the evil, as if I dropped a known-good
compressed file in there and uncompress it, all is well.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

-- Additional comment from jbj on 2004-08-27 16:36 EST --
(aside) This is file problem:
    .qa.[root@kryten jkt]# file anaconda
    anaconda: a /usr/bin/python2.2 script text executable

So the problem is 31093 != 9586 ?

FYI, the only change in ncompress -38 is
    s/long/long long/
easily reverted if not perfect.

-- Additional comment from jbj on 2004-08-27 19:23 EST --
Nah, thought znaconda.Z, not anacoda. never nind.

-- Additional comment from jturner on 2004-08-27 21:03 EST --
I haven't dug in too deeply, but am seeing this with -33 as well, so I
suspect the problem goes back quite a ways before -38.

-- Additional comment from kdrader.com on 2006-09-15 23:37 EST --
I tested compress with a couple of files. The resulting compressed
file is the expected size. That is, it is the same size that I get
when I compress the original file on an x86 system. The first three
bytes are 0x1f 0x9d 0x90 (the compress magic number) but the rest of
the bytes are null.

A 31-bit compress binary (from the s390 RPM) produces valid output.
This is pretty clearly a problem with the size of a "int" or "long
int" coupled with not handling endian-ness correctly.

I built the ncompress-4.2.4-44.1 source RPM from RHEL5 beta but it
behaves the same.

I've traced this to sizeof(long) == 8 in the s390x environment coupled with the 
little endian byte order. Replacing

    union   bytes
    {
        long     word;

with

    union   bytes
    {
        int     word;

results in a compress(1) command that produces correct output.

The compress(1) command produces the same invalid output on PowerPC-64 (ppc64) 
if compiled from source and the "-m64" compiler switch is employed. The only 
reason this hasn't been reported as a problem on ppc64 appears to be that a 32-
bit version of the program is installed.

This problem will affect any version of compress(1) compiled on a 64-bit little-
endian architecture where sizeof(long) == 4.


-- Additional comment from kdrader.com on 2006-09-15 23:59 EST --
Argh! My last sentence should say "problem will affect ...

    64-bit little-endian achitecture where sizeof(long) == 8.


-- Additional comment from jturner on 2006-10-30 06:51 EST --
QE ack for RHEL3.9.  Dup'ing for RHEL4 and RHEL5 as well.