Re: broken GC

[Rob Browning]

address@hidden (Thomas Bushnell, BSG) writes:

> It matters a great deal about what the rules are, not just that they
> are well documented.
>
> Emacs has perfectly clear rules for this, but it has proven to be
> *very* difficult to get C code correct in marking local variables for
> the garbage collector, and is a persistent source of very hard to
> track bugs.

Fair enough.  Since I posted that, I've heard enough about the Emacs
issues to suspect that for a precise GC to be a *really* viable
contender, some sort of code preprocessor would be a big help, but
then you would have to contend with all the problems associated with
maintaining something that can fully parse C code (whatever that
means).

This seems somewhat risky.  I'm worried that we could end up in
situations where our preprocessor expands a given source file
differently than the eventual target C compiler (gcc, the sparc
compiler, IBM's compiler, etc.), perhaps generating code that's
incompatible with non-guile-preprocessed code living in the same app,
or in other libraries on the system.

Imagine the case where a library uses "#" magic in it's header files
to select the size and layout of data structures.  If we don't handle
those "#" directives exactly the way that the target compiler will,
then we could be in trouble.  I suppose one solution might be to
require that any guile code has to be run through the preprocessor of
the target compiler first, before being handed to the GC preprocessor,
but is that really viable?

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD