9:21 a.m.
What you say about the way magic specifiers appear at the Lisp level is correct. However,
I
really don't think you should add needless extra parameters to any specifier
functions.
Instead, just decide that specifier-fallback definitely does not copy a specifier that it
returns, and maybe add a read only flag to specifiers if you don't want the ghost
specifiers
to be modified except during initialization time. For that matter, there would be no need
to
call copy-tree at all if it were possible to mark conses and vectors (and strings) as
read-only. This should be possible using minimal tag bits, and I think it would be a
great
feature to add as it would eliminate a lot of other places where lists are copied solely
to
avoid possible malicious code modifying them. Kyle? You could simulate this in the non-
minimal tag bits case by allocating read-only conses in their own frob blocks, and
probably
figure out a way to hack the flag into strings and vectors.
Kirill M. Katsnelson wrote:
Some time ago, Ben Wing wrote...
|+
| For the most part this looks very good, but I don't like the reveal ghost
specifiers
| mechanism. Instead, why don't you just have a flag that indicates whether the
ghost
| specifiers are read-only? This is true except during those Lisp initialization
| functions, which retrieve the ghost specifier using specifier-fallback. In your
| current scheme, unless I'm mistaken, naughty code could retrieve the ghost
specifier
| using specifier-fallback, and then modify it.
Oops, you are right, specifier-fallback uses copy-tree to return the fallback value,
but copy-tree does not copy specifiers, just returns its argument. Maybe copy-tree
and copy-sequence should be extended to the specifier case? Specifiers *are* the
objects copying which makes sence. Implementation is 2 lines of code worthy...
As for the reveal mechanism, I designed it with minimal changes to the hairy
initialization lisp code in mind. Anyways, what you propose really makes the design
clearer, and overweighs my consideration.
To avoid dependency on the behavior of specifier-fallback, i.e. whether it copies a
fallback specifier or not, may it be better to add one parameter to add-spec* and
remove-spec* functions, telling that these should operate on the ghost part of a
magic specifier, if it is really magic? This gives (maybe little) benefit in so that
lisp code should not care whether a specifier is a magic one, i.e. does it have a
ghost fallback or not.
| The purpose of the depth argument that you [Kirill] ask about is to catch inheritance
| loops, but I do not know if this is currently implemented.
Yes, this is implemented.
I already found out why this counter is passed to instantiate method: For faces, this
method may call specifier_instance again, with matchspec this time, thus possibly
creating an "external" loop, so it passes the counter back to
specifier_instance.
I will document the usage of this parameter.
| As for your suggestion about comparing fallbacks in the internal equal method, I
think
| this is a good idea.
Ok, I will add this.
| I'm glad that you documented the specifier methods, and I'm impressed with
the
| thoroughness and the clearness of the documentation.
Thanks.
| I think that you should add to the comment that explains magic specifiers, noting the
| difference between the ghost fallbacks (which contain the user preferences specified
| through window system resource files), and the fallback of the ghost fallback (which
| contains emergency backup values just to make sure that something minimally
reasonable
| happens).
And this, too.
I do not think that magic specifications should be documented at lisp level. For a lisp
program, a magic specifier is just a regular specifier, with another specifier as its
fallback, and there is nothing magic about it. Am I correct here?
Kirill
--
This message composed using voice recognition software and foot pedals.
(No keyboards were harmed while composing this message.)
10:08 p.m.
New subject: [PATCH] Ghost specifiers
Some time ago, Ben Wing wrote...
|+
| What you say about the way magic specifiers appear at the Lisp level is correct.
However, I
| really don't think you should add needless extra parameters to any specifier
functions.
| Instead, just decide that specifier-fallback definitely does not copy a specifier that
it
| returns, and maybe add a read only flag to specifiers if you don't want the ghost
specifiers
| to be modified except during initialization time. For that matter, there would be no
need to
| call copy-tree at all if it were possible to mark conses and vectors (and strings) as
| read-only. This should be possible using minimal tag bits, and I think it would be a
great
| feature to add as it would eliminate a lot of other places where lists are copied
solely to
| avoid possible malicious code modifying them. Kyle? You could simulate this in the
non-
| minimal tag bits case by allocating read-only conses in their own frob blocks, and
probably
| figure out a way to hack the flag into strings and vectors.
Ok, in the meantime, while there are no "read-only lrecords", I'll do
read-only specifiers.
Kirill
12:29 a.m.
New subject: [PATCH] Ghost specifiers
Ben Wing writes:
[...] For that matter, there would be no need to call copy-tree
at all if it were possible to mark conses and vectors (and
strings) as read-only. This should be possible using minimal
tag bits, and I think it would be a great feature to add as it
would eliminate a lot of other places where lists are copied
solely to avoid possible malicious code modifying them. Kyle?
I have no idea what this is all about, but it is possible. With
USE_INDEXED_LRECORD_IMPLEMENTATION, there is room in the lrecord
header for property bits. Checks for the read-only bit would be
in the same places that CHECK_IMPURE is used now.
8:29 a.m.
New subject: [PATCH] Ghost specifiers
In the specifier code and in a lot of other code that I wrote, I had to
copy internal lists whenever they were returned just to make sure that
malicious code couldn't mess things up by modifying them. This is
inefficient, and could be avoided if we had read-only lists. The same
thing goes for strings, although they aren't generally copied.
Kyle Jones wrote:
Ben Wing writes:
> [...] For that matter, there would be no need to call copy-tree
> at all if it were possible to mark conses and vectors (and
> strings) as read-only. This should be possible using minimal
> tag bits, and I think it would be a great feature to add as it
> would eliminate a lot of other places where lists are copied
> solely to avoid possible malicious code modifying them. Kyle?
I have no idea what this is all about, but it is possible. With
USE_INDEXED_LRECORD_IMPLEMENTATION, there is room in the lrecord
header for property bits. Checks for the read-only bit would be
in the same places that CHECK_IMPURE is used now.
--
This message composed using voice recognition software and foot pedals.
(No keyboards were harmed while composing this message.)
6:43 p.m.
New subject: [PATCH] Ghost specifiers
On Fri, May 01, 1998 at 12:29:42AM -0700, Ben Wing wrote:
In the specifier code and in a lot of other code that I wrote, I had
to
copy internal lists whenever they were returned just to make sure that
malicious code couldn't mess things up by modifying them. This is
inefficient, and could be avoided if we had read-only lists. The same
thing goes for strings, although they aren't generally copied.
What do you want exactly, read-only or copy-on-write ?
OG.
8:28 p.m.
New subject: [PATCH] Ghost specifiers
Some time ago, Olivier Galibert wrote...
|+
| On Fri, May 01, 1998 at 12:29:42AM -0700, Ben Wing wrote:
| > In the specifier code and in a lot of other code that I wrote, I had to
| > copy internal lists whenever they were returned just to make sure that
| > malicious code couldn't mess things up by modifying them. This is
| > inefficient, and could be avoided if we had read-only lists. The same
| > thing goes for strings, although they aren't generally copied.
|
| What do you want exactly, read-only or copy-on-write ?
|-
I haven't been thinking yet about what could COW buy us. But it looks very
hard to implement it, because if an object (say cons) is modified, all
pointers to it have to be adjusted, like
; a is a read-only cons (1 . 2)
(setq b a)
(setcar a 3)
; Now both a and b must point to the same copied rw cons (3 . 2)
Kirill
9702
days inactive
9703
days old
5 comments
4 participants
participants (4)
-
Ben Wing -
Kirill M. Katsnelson -
Kyle Jones -
Olivier Galibert