Path: utzoo!utstat!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!olivey!jerry
From: jerry@olivey.olivetti.com (Jerry Aguirre)
Newsgroups: news.software.b
Subject: Re: expire oink
Message-ID: <49326@olivea.atc.olivetti.com>
Date: 30 Aug 90 22:35:48 GMT
References: <1990Aug22.165739.6918@lethe.uucp> <49312@olivea.atc.olivetti.com> <1990Aug30.162009.2017@zoo.toronto.edu>
Sender: news@olivea.atc.olivetti.com
Organization: Olivetti ATC; Cupertino, CA
Lines: 21

In article <1990Aug30.162009.2017@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>It's quite random, but for 800KB that should not be a disaster on a
>system with a reasonable amount of memory.  If you're running dbz version
>3 (the one distributed with C News), you can find out the exact size of
>the table:  cat history.dir (it's a text file), take the second number
>on the first line, multiply by sizeof(long) (normally 4).

The dbz file looks like:

	dbz 3 999983 9 = 128 127 24 4 0 1 2 3
	265832 0 0 0 0 0 0 0 0 0 0

From which I calculate a 4 Meg size using Henry's formula.  That is for
a history file with 269616 lines.  I confess to raising the initial size
define based on recomendations for a large history file.

I seem to remember ps reporting expire as using 11 Meg on a 386 system
though.  (Not currently available for me to verify this.)  I wasn't too
concerned because I had 16 meg of physical memory.

Perhaps there is a sizeof or malloc bug involved.