From owner-freebsd-current  Mon Jul 29 14:06:41 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id OAA22693
          for current-outgoing; Mon, 29 Jul 1996 14:06:41 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA22682
          for <current@FreeBSD.org>; Mon, 29 Jul 1996 14:06:09 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id HAA14363; Tue, 30 Jul 1996 07:05:13 +1000
Date: Tue, 30 Jul 1996 07:05:13 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199607292105.HAA14363@godzilla.zeta.org.au>
To: bde@zeta.org.au, wollman@lcs.mit.edu
Subject: Re: no prototype for zopen
Cc: charnier@xp11.frmug.org, current@FreeBSD.org
Sender: owner-current@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

>I'm aware of only one program which uses the zopen(3) interface to
>compress(1), and that's `savecore'.  I don't think anyone would be

That's one more than I was aware of yesterday :-).

>hurt to simply remove the functionality in its entirety.  Doesn't save
>much space, though...

It also probably saves less space in the output file than would gzipping
the output.  The only case where it helps is if the file system is too
small to hold the initial output.

>Furthermore, not being in any system libraries, it doesn't belong in
>any header files.  Perhaps a zopen.h in the sources to compress if we
>should decide to keep it.  (I would just as soon get rid of compress
>entirely.)

I think requiring a header for exported functions would be a good rule.
We already have a similar rule for (often not even exported) path
names.

Bruce