Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ucla-cs!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: Daylight Savings Time: how to fix ctime.c
Message-ID: <15432@sun.uucp>
Date: Sat, 21-Mar-87 16:28:26 EST
Article-I.D.: sun.15432
Posted: Sat Mar 21 16:28:26 1987
Date-Received: Sun, 22-Mar-87 17:55:52 EST
References: <5040@brl-adm.ARPA> <717@rtech.UUCP>
Sender: news@sun.uucp
Reply-To: guy@sun.UUCP (Guy Harris)
Organization: Sun Microsystems, Mountain View
Lines: 31

>Actually, a shared library seems more appropriate (equally great for
>us BSD types).

No, because it would be a bigger pain to replace a shared library if
the rules change.

Another "no" to both is that shared libraries *and* shared memory
segments are extensions to the SVID.  Some implementations may have
difficulty implementing either or both, due to hardware limitations,
and may in fact not implement them.

(Note that some future BSD release may implement "mmap", which can
give you both shared data *and* shared libraries; some people who
started with 4.2BSD or 4.3BSD kernels have added various flavors of
"mmap", S5 shared memory, or shared libraries to them.)

>Another thought:  load the tables into an environment variable at login
>time, a la TERMCAP.

If you loaded them in binary form, it would be fun to watch people
use the "(print)env" command(s).  If you loaded them in ASCII string
form, it would chew up a fair bit of your argument list space (thus
significantly reducing the number of bytes of arguments you could
pass to commands).  I'd also want to see actual timing tests before I
believed that this was a net performance win (remember, even if you
fork and exec a program that *doesn't* do time conversions, you still
have to copy the environment).

(I'm still not sure why people are trying to come up with
alternatives to code that's publicly available and that seems, at
least in my tests, to have adequate performance.)