home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!charon.amdahl.com!amdahl!fadden
- From: fadden@uts.amdahl.com (Andy McFadden)
- Newsgroups: comp.compression
- Subject: Portability issues for archiver authors
- Message-ID: <92tI03Lyc5EL00@amdahl.uts.amdahl.com>
- Date: 22 Dec 92 00:00:39 GMT
- Reply-To: fadden@amdahl.uts.amdahl.com (Andy McFadden)
- Organization: Amdahl Corporation, Sunnyvale CA
- Lines: 42
-
- I'm in the process of porting a whole pile of archiving programs to UTS4.0
- (Amdahl's SVR4 implementation). The most common portability problem is the
- use of 8-byte file offsets.
-
- This means that our seek prototypes look (more or less) like this:
-
- off_t lseek(int, off_t, int);
- off_t fseek(FILE *, off_t, int);
- off_t ftell(FILE *)
-
- where off_t is 8 bytes instead of the usual 4 byte long.
-
- (Actually, ANSI specifies that the second argument to fseek() is an unsigned
- long, but if you're using ANSI prototypes then the problem will go away by
- itself anyway.)
-
- Also, the st_size field of struct stat is an off_t.
-
- So, I usually wander through and case stuff to off_t; no big deal. However,
- "hpack" had a particularly egregious problem: the author defined LONG as
- *unsigned* int, which meant that this:
-
- (off_t) ((LONG) -1)
-
- evaluates to 0x00000000ffffffff, which is not at all what was intended. I
- ended up doing (off_t) ((long) (x)), which worked. Took a little while to
- find though.
-
- (The other thing that bit me was the case conversion on a static string;
- apparently with the OS and compiler I'm using, changing a staticly allocated
- string is a no-no... something like functionCall("*").)
-
-
- So far the portability award goes to ZIP, which (with ANSI prototypes enabled)
- compiled and worked the first time. UNZIP is next; the lseek calls had to
- be tweaked. ARC was sort of annoying, but I got it to work. HPACK is dead
- last, which is surprising since its primary reason for existence seems to be
- archiving across platforms. Haven't tried ZOO or UNARJ yet.
-
- --
- fadden@uts.amdahl.com (Andy McFadden)
- [ Above opinions are mine, Amdahl has nothing to do with them, etc, etc. ]
-