[gclist] FAQ update

[johan@dcs.gla.ac.uk]

I've been reading the FAQ, so as not to ask too many stupid questions,
but it didn't work. :-) 

I came accross the following passage:

>                         ... Most programs don't do these things,
> so most programs work with a garbage collector. Ordinary (legal)
> pointer arithmetic is tolerated by garbage collectors for C.

I don't quite get the last claim. How do you reconcile pointer
artihmetic with [for example] mark-sweep GC? I can rephrase my 
confusion as:

 How does the collector determine object boundaries in the context of 
 a non-gc aware compiler so that the entire object gets marked and
 all pointers in it get followed, and not just part thereof?

I assume that malloc stores information about the size of an allocated
object somewhere (for example, it might store it in the locations just
preceeding the allocated block). If there was a defined standard for
this, the garbage collector could recover this information and deal
with the entire object. However, when the program starts to do pointer
arithmetic, the scheme I gave as an example above no longer works.
An example would be stripping leading spaces in a C string; the collector 
would have to start searching backwards looking for the presumed malloc-
info block. If it erroneously decided to have found an info block and 
tried to parse it, havoc would ensue.

The only solution I can think of is to have some explicit object
boundary table (which could be HUGE), or some other implicit scheme
(objects in address range [A..B] all start on memory locations
devisible by x, f.ex). Both approaches seem, well, not quite
acceptable.

Obviously, I am missing something. 

johan