Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!math.lsa.umich.edu!hyc
From: hyc@math.lsa.umich.edu (Howard Chu)
Newsgroups: comp.os.minix
Subject: Re: LHARC available for MINIX!
Keywords: lharc archive compress
Message-ID: <1990Jul12.003850.26147@math.lsa.umich.edu>
Date: 12 Jul 90 00:38:50 GMT
References: <781@rossignol.Princeton.EDU> <1990Jul3.011235.5774@jarvis.csri.toronto.edu> <784@rossignol.Princeton.EDU>
Sender: usenet@math.lsa.umich.edu
Organization: University of Michigan Math Dept., Ann Arbor
Lines: 64

In article <784@rossignol.Princeton.EDU> nfs@cs.Princeton.EDU (Norbert Schlenker) writes:
%Here is the Lharc header structure from the Unix source that I have.  It
%is possible that this structure is from an old version, but this is from
%the most recent posting in comp.sources.misc.
%
%typedef struct LzHeader {
%  unsigned char		header_size;
%  char			method[METHOD_TYPE_STRAGE];
%  long			packed_size;
%  long			original_size;
%  long			last_modified_stamp;
%  unsigned short	attribute;
%  char			name[256];
%  unsigned short	crc;
%  boolean		has_crc;
%  unsigned char		extend_type;
%  unsigned char		minor_version;
%  /*  extend_type == EXTEND_UNIX  and convert from other type. */
%  time_t		unix_last_modified_stamp;
%  unsigned short	unix_mode;
%  unsigned short	unix_uid
%  unsigned short	unix_gid;
%} LzHeader;
%
%This header CANNOT be portable between machines.  It depends on the
%size of short integers (usually 16 bits, but they don't have to be),
%on the size of long integers (usually 32 bits, but ...), on the
%endianness of the machines which read and write the archive, on the
%padding between structure elements, and on the fact that Unix modes,
%uids, and gids all fit into unsigned short integers.
%
%These assumptions cannot be guaranteed, even on the limited range of
%machines that Minix runs on.  They are certainly not guaranteed in the
%Unix range.  Lharc archives produced with the above header on my PC
%can be read on a VAX here.  The same archive cannot be read on a Sun-4
%(byte order and structure padding problems) nor a DEC 5400 (an endian
%and structure padding problem) nor a MIPS box (a structure padding
%problem).  I have little hope that they will be readable on the next
%fast box that is installed here.

At least in ARC, all that matters is if a certain type is *at least*
X bits large. If a short is 16 or 18 bits is irrelevant, and the difference
between 32 and 36 bits is also no problem. With the ARC port, the
ARC header is defined as a struct, but it is read from the archive
one byte at a time, and assembled into the internal format by the
header processing routines.

The exact layout & sizes of fields in the structure is irrelevant.
All that matters is what you do when you pull the structure into memory
and shove it back out again. It's trivial to write a single routine
that will do this correctly on *any* architecture. This is what I
did for ARC. My port of ARC runs on Crays, PCs, 68000s, IBM 3090s,
Vaxen, MIPS, Sparc, and some other more obscure architectures...

So enough of this noisemaking over non-portable header definitions.
It's just Not A Problem. If your versions of Lharc are incompatible
across your various systems, then you probably have an outdated
version or the guy who ported it was inept.

--
  -- Howard Chu @ University of Michigan
  one million data bits stored on a chip, one million bits per chip
	if one of those data bits happens to flip,
		one million data bits stored on the chip...