Re: The relationship between SCM and scm_t_bits.

[Marius Vollmer]

Dirk Herrmann <address@hidden> writes:

> I have not yet given it a try, but I found the suggestion to use a
> union quite appaling:

[ I think you mean "appealing". :-) I used to mix up the adjectives
  "content" and "contempt"...  [ And its "appalling" with double-el.
  I hope you don't mind this little public correction.  [ I think I
  can get away with it since I make a ton of mistakes myself... ] ]
]

> [...]
>
> typedef struct scm_t_cell
> {
>   union {
>     scm_t_bits word;
>     SCM object;
>   } elements[];
> } scm_t_cell;

Yes, but consider how we use the heap: we fetch a word and then must
decide whether it is a SCM or a scm_t_bits, we don't know this in
advance in every case.  This is not really supported by a union: I
don't think you can store into one member and then (portably) assume
anything about the value read from a different member.  This is very
much like storing into one memory location thru one pointer and
reading that same location through a differently-typed pointer.  I
therefore don't think that using a union is an improvement.

(It will work on all 'normal' platforms, of course, just like casting
the pointers worked, but I would like to get away from relying on this
non-portable behavior.)

Thus, I think we are better off by just declaring the heap words to be
of type SCM and always accessing them as this type.  Converting
between SCM and scm_t_bits will happen with SCM_PACK and SCM_UNPACK.
That way, we don't need to assume that a SCM and a scm_t_bits are
stored identically in memory.

(And incidentally, we don't use scm_t_cell that much in Guile anyway.
We should maybe remove it.  I tried recently but didn't finish since
it turned out to be quite some amount of work to get all size
statistics in the GC correct.)

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405