Re: allout patch - more safe-local-variables, plus autoloads

[Luc Teirlinck <teirllm@dms.auburn.edu>]

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.