Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Precompiled wordcode zsh functions
- X-seq: zsh-workers 9874
- From: Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: Precompiled wordcode zsh functions
- Date: Fri, 25 Feb 2000 11:42:54 +0100 (MET)
- In-reply-to: "Bart Schaefer"'s message of Fri, 25 Feb 2000 09:44:11 +0000
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
Bart Schaefer wrote:
> ...
>
> } [...] we would need to have a wordcode-verifier [...]
>
> How does emacs assure the integrity of .elc files? Or does it?
Dunno. What I'm worried about is that the parser catches wrong shell
code, but for wordcode... (of course, modules have the same problem,
probably even worse).
> } That's yet another reason for having only a scalar containing
> } only one directory name (so $COMPILED_FDIR might be a better name) --
> } save compiled functions only if that is set and names an existing,
> } writable directory. Users would set it to a directory in their account
> } so that others can't trick them into using evil code.
>
> Zsh should probably already be more paranoid than it is about loading
> modules or functions from widely-writable directories or files. But
> that has nothing to do with how many such directories or files are
> involved. Where does "save compiled functions" come in? I'd think
> we'd want an explicit "zcompile" builtin so functions can selectively
> be compiled or not. I don't want it just automatically writing out
> wordcode for every function it ever loads.
In the light of Andrej's last comments, how about:
Add a builtin (`zcompile' if you wish), that gets a list of
filenames. The first one is used as the file to write the code for all
functions named by the other filenames into. These have to name
existing function files (not necessarily in $fpath). So the generated
file is a kind of digest containing the code for multiple functions.
Then: $fpath may also contain names of such digest files. In
getfpfunc() (that's where we load autoloaded functions), if the name
of a digest file in $fpath is found, the file is searched for the
definition of the function we are seeking. If it contains this
function, the thing is mapped and the Eprog is set up. We would keep a
list of already mapped files, of course, and if all functions used in
such a file are re-defined or unfunction'ed, we unmap it.
One problem: should there be some warning if the digest file is older
than the function file (if that is reachable through $fpath)? I.e. do
we have to test that?
Second problem: functions like _cvs that essentially just define lots
of functions and re-define themselves[1]. The mapped function would of
course be the short lived function-defining one.
Bye
Sven
[1] I was always against doing it that way ;-)
--
Sven Wischnowsky wischnow@xxxxxxxxxxxxxxxxxxxxxxx
Messages sorted by:
Reverse Date,
Date,
Thread,
Author