[gclist] Re: gclist-digest V1 #61

[Robert A Duff]

"Richard A. O'Keefe" <ok@cs.rmit.edu.au> says:

> On the other hand, it has been explicit for some time that Ada *may*
> be garbage collected, and where are the garbage collecting Ada 
> implementations?

Intermetrics has one, I hear.  Historically, Ada implementations have
not done gc.  However, as gc becomes more popular in the main-stream
procedural-language realm, I suspect Ada implementations will get gc'ed.
Same for C++.  (Ada and C++ are in essentially the same boat for gc,
although Ada makes the gc's life a *little* bit easier.  And the Ada
standard already has the necessary wording that defines hidden pointers
to be evil.)

The Intermetrics implementation has gc just because its target is Java
byte-codes.  I believe there was an implementation of Ada on Symbolics
Lisp machines that supported gc, too.  I believe somebody is working on
a gc for GNAT (the GNU Ada compiler).

>...  Perhaps it will be the same with C++.

> As far as a programmer is concerned, there are three situations:
> (1) The programmer has code using disguised pointers which will not
>     work with a garbage collector.
> 
> 	This programmer needs a way to FORBID garbage collection.

Well, maybe this programmer would like to have hooks that tell the gc
what's what.  These "evil tricks" are pretty useful from time to time.
(After all, most pointers have a couple of wasted bits at the low end,
since heap objects are typically aligned on a 4-byte boundary.  I would
like to have a compiler that can pack a record, containing a pointer and
two Booleans, into 32 bits, but most can't, so if I really want that, I
have to resort to evil tricks.  The tricks may be evil, but in this
particular case, cuts space in HALF!  And space is time, on modern
cached machines.)

"Stefan Monnier" <stefan.monnier@lia.di.epfl.ch> says:

> So, it's always safe to implement unions like structs.

I believe it's always correct as far the ANSI C standard is concerned,
and the C++ standard (if such ever exists), but it might break some
people's programs.  Sigh.

> > However, the standard also states: "A structure type
> > describes a sequentially allocated nonempty set of member objects
> > [....] A union type describes an overlapping nonempty set of member
> > objects [....]" (section 6.1.2.5).
> 
> This is really only a hint to the implementor about what is usually meant,
> but doesn't have to be enforced since the semantics are weak enough (see the
> above paragraph) that a program can only tell the difference by relying on
> implementation-defined behavior.

Right.  I presume that "overlapping" is not formally defined by the
standard.

- Bob