From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: allout patch - more safe-local-variables, plus autoloads Date: Wed, 19 Apr 2006 21:47:56 -0500 (CDT) Message-ID: <200604200247.k3K2luJe016211@jane.dms.auburn.edu> References: <2cd46e7f0604171211s5ef0e820gebc4e68b2ce2606d@mail.gmail.com> <8764l7m40w.fsf-monnier+emacs@gnu.org> <87r73uji3b.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1145501345 17363 80.91.229.2 (20 Apr 2006 02:49:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 20 Apr 2006 02:49:05 +0000 (UTC) Cc: ken.manheimer@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 20 04:48:56 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FWPDt-0007KM-Gv for ged-emacs-devel@m.gmane.org; Thu, 20 Apr 2006 04:48:49 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FWPDt-00028O-4R for ged-emacs-devel@m.gmane.org; Wed, 19 Apr 2006 22:48:49 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FWPDh-00027w-5K for emacs-devel@gnu.org; Wed, 19 Apr 2006 22:48:37 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FWPDg-00027k-Hl for emacs-devel@gnu.org; Wed, 19 Apr 2006 22:48:36 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FWPDg-00027h-CU for emacs-devel@gnu.org; Wed, 19 Apr 2006 22:48:36 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FWPEs-0004Js-5w; Wed, 19 Apr 2006 22:49:50 -0400 Original-Received: from jane.dms.auburn.edu (jane.dms.auburn.edu [131.204.53.201]) by manatee.dms.auburn.edu (8.13.6/8.13.6) with ESMTP id k3K2mUWf006504; Wed, 19 Apr 2006 21:48:30 -0500 (CDT) Original-Received: from jane.dms.auburn.edu (localhost [127.0.0.1]) by jane.dms.auburn.edu (8.13.4+Sun/8.13.3) with ESMTP id k3K2luQ4016214; Wed, 19 Apr 2006 21:47:56 -0500 (CDT) Original-Received: (from teirllm@localhost) by jane.dms.auburn.edu (8.13.4+Sun/8.13.3/Submit) id k3K2luJe016211; Wed, 19 Apr 2006 21:47:56 -0500 (CDT) X-Authentication-Warning: jane.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: rms@gnu.org In-reply-to: (message from Richard Stallman on Wed, 19 Apr 2006 17:12:25 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:53117 Archived-At: Richard Stallman wrote (in response to Stefan Monnier): If we disallow t and want a quick&dirty replacement predicate for boolean values, we can either introduce booleanp (seems like a good predicate to have around anyway) or just use symbolp. symbolp is not correct; a boolean variable can have any Lisp object as its value. If booleanp is mean to mean "is t or nil", that would also be incorrect. This is not about correctness, but about safety. Any non-nil value for a minor mode variable is "correct", in that it is equivalent with t, but why would anybody actually _want_ to use any other value than t in a local variables list. If anybody actually did it, I would want to see it because it would make me suspicious. Currently, putting: ;;; no-byte-compile: (funcall (lambda () ... some hairy code ... )) in a local variables list gets evaluated without asking, because `no-byte-compile' has a safe-local-variable property of t. The "hairy code" is not tested for safety at all. I checked this using obviously unsafe code. But if you got asked, would you really just immediately respond yes without taking a look at that lambda expression, because that lambda expression is equivalent with t anyway and hence perfectly "correct"? If I really believed that the above code currently could be exploited in harmful way, I would not be posting it publicly. For it to do harm, no-byte-compile should be evaluated twice as in (eval no-byte-compile), although there are other ways to produce repeated evaluation than using eval. If somebody tried to get (eval no-byte-compile) or similar evaluated elsewhere in the local variables list, then the user would get asked about _that_. (Otherwise this would be a serious bug). But as we keep increasing the number of boolean variables with a safe-local-variable property of t, then the probability increases that by some freakish accident one of these boolean variables gets evaluated twice in the Emacs source code. This would be a bug, because the boolean variable can take any value and hence should not be evaluated twice. But in practice, one always uses t or nil as values, so the bug could easily escape detection for a long time (unlike similar bugs for variables that are normally lists, where the double evaluation would immediately throw an error, exposing the bug). The above scenario might not seem excessively likely but why take _any_ risk, since there is no good reason to use non-nil values other than t for boolean variables in a local variables list? I do believe that for variables of type DEFVAR_BOOL all values are completely safe, since they get immediately translated to nil or t anyway. Sincerely, Luc.