From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8905 invoked from network); 25 Feb 2000 10:45:55 -0000 Received: from postoffice.telstra.net (HELO tpostoffice.telstra.net) (203.50.1.76) by ns1.primenet.com.au with SMTP; 25 Feb 2000 10:45:55 -0000 Received: from sunsite.auc.dk (sunsite.auc.dk [130.225.51.30]) by tpostoffice.telstra.net (8.9.3/8.9.3) with SMTP id VAA39170 for ; Fri, 25 Feb 2000 21:45:27 +1100 (EST) (envelope-from zsh-workers-return-9874-mason-zsh=primenet.com.au@sunsite.auc.dk) Received: (qmail 12468 invoked by alias); 25 Feb 2000 10:43:18 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9874 Received: (qmail 12460 invoked from network); 25 Feb 2000 10:43:17 -0000 Date: Fri, 25 Feb 2000 11:42:54 +0100 (MET) Message-Id: <200002251042.LAA25724@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Fri, 25 Feb 2000 09:44:11 +0000 Subject: Re: Precompiled wordcode zsh functions 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