lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev [PATCH][dev21] the binary size battle: disabling charsets


From: Klaus Weide
Subject: Re: lynx-dev [PATCH][dev21] the binary size battle: disabling charsets
Date: Wed, 31 Mar 1999 12:02:34 -0600 (CST)

On Tue, 30 Mar 1999, Bela Lubkin wrote:

> John Bley wrote:
> 
> > Here's an idea for allowing extra rope to hang yourself on binary size: 
> > disabling all the character sets except ISO-8859-1 and 7-bit ASCII 
> > approximations.  It makes for a roughly 79KB decrease (here).
> 
> I suggested what I still believe is a better path in this matter: make
> the character sets dynamically loadable.  The two defaults you've chosen
> should probably continue to be hard-compiled in.  That way a bare Lynx
> binary which has become dissociated from its support files is still more
> or less usable.

Is it a good thing that a Lynx dissociated from its support files is still
usable?

Lynx intentionally refuses to work when it finds no configuration file.
None of the lynx.cfg is really required for running: lynx -cfg=/dev/null
runs.

This has advantages.  It's nearly impossible to _accidentally_ install
lynx without a lynx.cfg.  And if the lynx.cfg somehow gets lost, the
problem becomes apparent immediately.
That's in addition to considerations for anonymous or otherwise restricted
accounts.

For chartrans tables, we currently don't have to deal with error reports
caused by character set files not found in right location, or messed up
by user, or wrong format version.  The Lynx version + current .cfg and
options settings are enough to reproduce a problem.  That would change.

> I would guess that the code to handle loading charsets as needed would
> be perhaps 1-2K of binary size.  So we'd still get about the same net
> gain, except *everyone* would get it, and we wouldn't have to think
> about whether to turn it on.

I think you greatly underestimate the effort.  1-2K - no way.  (Pick up
the challenge and prove me wrong...)

There's also the runtime overhead of loading those files at program start.
Or, if loading is not happening at startup but on demand, additional logic
is needed to pre-register available charsets - either at installation time
(losing part of the flexibility advantage, and introducing additional error
modes) or at startup (requiring at least lots of stat()s).

    Klaus


reply via email to

[Prev in Thread] Current Thread [Next in Thread]