Re: [RFC] temporary Lisp_Strings

[Paul Eggert <eggert@cs.ucla.edu>]

What would the GC do when it sees such a string?  Wouldn't this make the 
GC a bit less robust, as it couldn't diagnose bogus strings any more 
when GC_CHECK_MARKED_OBJECTS is defined?

Like Stefan, I wonder how much performance benefit you're really gaining 
here.  Presumably most of it is lack of pressure on the GC, and how do 
you measure that?

I assume you're thinking of eventually doing this for conses etc. too?

Dmitry Antipov wrote:
> is there a way to make sure that an address returned by alloca fits in Lisp_Object?

It should work on typical platforms, as alloca should return an address 
that is aligned well enough for Emacs, just as malloc does.  Perhaps we 
may run into an oddball platform where alloca isn't suitably aligned, 
but if so we can simply allocate a few more bytes than needed and then 
align the pointers ourselves.  For starters, though, I'd just assume 
that it's aligned.  An Emacs built with ENABLE_CHECKING should verify 
any alignment issues already, as make_lisp_ptr checks for this.

We don't need to worry about !USE_LSB_TAG on the trunk anymore, as 
support for abusing the high-order bits of pointers has been withdrawn 
on the trunk.