[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev [PATCH][dev21] the binary size battle: disabling charsets
From: |
Bela Lubkin |
Subject: |
Re: lynx-dev [PATCH][dev21] the binary size battle: disabling charsets |
Date: |
Wed, 31 Mar 1999 15:09:56 -0800 |
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<