[Sorry for the delay]
[You're not on -beta, Ben, right ?]
On Sat, Dec 18, 1999 at 04:31:56AM -0700, Ben Wing wrote:
a. a read-only bit. I think this already exists, in fact. Just mark
the string
read-only while iterating over it; then modify the few functions that change
strings (aset, set-string-property, etc.) to reflect the read-only state and
signal an error. You could even implement this for conses; then, you could mark
the whole list that you're iterating over as read-only (by marking each cons),
and you wouldn't run into any of these crashes.
There are tons of other places in XEmacs where having read-only lists and strings
would be truly wonderful. Currently, all over XEmacs there are places where
internal data is copied before being returned as a return value -- especially in
the specifier and glyph code -- to make sure that it's impossible for someone to
modify and thereby mess up internal data. Huge amounts of copying could be
eliminated through read-only lists and strings. Implementation should be easy --
Olivier?
Hrvoje already replied[1], but as a generic rule of thumb I'd be
happier if we could avoid per-lrecord flags entirely. They don't cope
well with Jan[2]'s very nice idea on how to avoid the lrecord headers,
which gives us faster allocations[3], sharing[4], and a 33% size gain
on conses[5][6].
OG.
[1] What _is_ this string modified tick btw?
[2] It was Jan, right?
[3] Every fixed size alloc gets an equivalent of a lrecord-list.
[4] The markbit jumps outside of the object.
[5] 12 to 8 bytes on 32 bit computers, 24 to 16 on 64 bit ones.
[6] ETOOMANYFOOTNOTES