Re: [EXPERIMENT] Emacs with the SpiderMonkey garbage collector

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

Pip Cet wrote:

> If my understanding is correct, signals can occur after every instruction,
> including in the middle of a call sequence while the argument, or
> return value, is unprotected).

Yes, that's right.

> Another thing is nested structs/enums/unions. I think those are bad
> style in addition to presenting a portability concern, even though
> they're easy to catch for the converter.

It should be OK to fix these, on style grounds. I assume the changes are 
relatively minor.

> The most vexing issue for me right now is that I haven't figured out
> how to get gnulib working with g++ without modifying files after every
> sh autogen.sh, though. I admit I don't understand the gnulib build
> process at all, so any hints would be appreciated.

Emacs has a special way of using Gnulib, unfortunately. I wrote the Gnulib 
interface (sorry! :-) and so can perhaps be of help here. What sort of 
modifications are needed after autogen.sh? Perhaps we can lessen and/or 
eliminate the need for them.

> The other issues are minor (a union and a typedef sharing a name, C++
> keywords, enums treated as ints),

If you would submit patches to fix these, that might help you in future merges. 
Of the three, enums treated as ints seems like it'd be the most hassle, as enums 
are the only way that C has to name small ints that can be used where an integer 
constant expression can be used. I'd hate to have to cast these names to int 
every time I used them, just to pacify C++. Perhaps the enum-to-int business 
could be handled by the C-to-C++ translator instead.

> What do you think about the future of pure space? That also seems to
> me to be an optimization that might no longer be worth it, and perhaps
> to add even more complexity to the code than dumping does.

I tend to agree that pure space is no longer worth the hassle.

>>> [1] - there's one place that uses "false" for "NULL"
> Patch attached.

Thanks, I installed that in your name in the master branch.