Re: Precompiled wordcode zsh functions

[Sven Wischnowsky <wischnow@informatik.hu-berlin.de>]

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@informatik.hu-berlin.de