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

[Bela Lubkin]

Klaus Weide wrote:

> On Tue, 30 Mar 1999, Bela Lubkin wrote:

> > 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 was last discussed when Fote was still running the show.  It seemed
to be a religious matter with him, so I didn't push my point of view.  I
think that yes, it *is* a good thing that a bare Lynx binary can run.
As you say, nothing is actually needed from lynx.cfg.  I often need an
ad hoc Lynx binary on a bare machine where I'm not root.  I can copy the
binary over; I can't copy the support files into the compiled-in
locations they're expected to be in.  I can dork around with environment
variables or flags.  I don't *want* to.  The only thing that prevents a
bare Lynx binary from running is its insistence on reading a file that
it doesn't need.  Silly.

> 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.

Yeah, it becomes apparent immediately, and ticks me off.  Every time.

> That's in addition to considerations for anonymous or otherwise restricted
> accounts.

I don't see any interaction with these.  If your anonymous/restricted
user can get out to a prompt and run arbitrary binaries (such as a Lynx
which has been compiled for a lynx.cfg path other than the one your
system uses), he's already busted out of his sandbox.

> 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.

True; like most new features, it would add some complexity.

> > 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).

I envisioned it as on-demand loading, so that in a session where (say)
you only looked at the 7-bit ASCII Lynx Help files, other tables
wouldn't have been loaded at all.

You imply that we need to know ahead of time which charsets are
available.  I couldn't find that in the code.  For instance, we
construct accept-charsets headers only from user input (lynx.cfg,
.lynxrc, or options menu); those could be checked when they're entered
(verify that matching charset files exist).  Other than that, we
construct a menu in LYOptions.c, and several functions in UCdomap.c
search for a charset by mime name.  In all cases it looked like the
functions could first search the already-loaded list, then (if
necessary) the directory where charset data is stored.

>Bela<