[gclist] What to say about GC.

[Richard A. O'Keefe]

	On the other side of the coin, a few years ago, I was writing a symbolic algebra
	program in a language that was still under development, and I found that my
	program would run fine for about an hour, then it would crash in an obscure way
	after a GC.

	The sort of behaviour above has possibly give GC a very bad name with those
	who have had that sort of trouble.

How is this different from any other bug in the support for your language?
My latest example:
    an absolutely clean small Pascal program with no records, unions,
    pointers, or anything except integers and reals.  Everything is
    exactly where the compiler put it.  Compiler: SPARCompiler Pascal 4.0.
    Compile it with the -fast option, and Ka-BOOM!
    After a lot of flailing around, narrow it down to
    Compile it with the -dalign option, and Ka-BOOM!
    Apparently this compiler, with this option, *assumes* but does not
    *ensure* that Reals are 8-byte aligned.

This is precisely the same sort of behaviour:  a documented feature of the
language has a bug in it.
    
Another example:
    About 8 years ago, I was working in a company that had a program that
    had successfully ported to quite a few UNIX machines.  The program was
    behaving very mysteriously, and after about 8 man-days of debugging
    time it was narrowed down to a single instruction.  It was something
    like this:
	unsigned x, y; .......
	if (x < y) ...
    The compiler had generated the right unsigned comparison instruction,
    but the assembler had assembled it wrong.  The code was branching on
    the *opposite* condition.

Another example:
    Just now while typing this reply I ran into a printf() bug in a
    certain C compiler.  The statement is
	clock_t t0, t1;
	...
->	printf("%g\n", ((long)t1 - (long)t0)/(double)(CLOCKS_PER_SEC));
    I happen to know from an earlier run that t1 - t0 is approximately
    12590 and from looking at time.h that CLOCKS_PER_SEC is 60, so the
    right answer is approximately 210 seconds.  What appeared on the
    screen was
	somethingE-457
    which is out by a ridiculous number of orders of magnitude.
    I *suspect* that the problem is that I compiled with double set to
    be native 68881 64-bit doubles, but that the code for printf assumes
    double is long double is SANE extended.  Alas, apparently there _is_
    no provided version of printf() that gets this right 

    I find this example quite comparable to the bug-in-GC one.  There is
    a mistake in the support for a basic facility defined by the language
    standard.  Does that say to me "oh, printf is wrong, never use it
    again"?  Does that even say to me, "oh, C is bad, never use it again"?
    Nope.  It tells me *that* version of *that* compiler is broken,
    and that's all.

There is a *reason* why whenever I compile a C program that really matters
to me I put it through lint, lclint, gcc, cc, and lcc, and when I had
access to CenterLine, through clcc as well.  If I could remember which of
the 6 compilers I used yesterday crashed, I'd tell you.  (I can remember
that it _wasn't_ Stalin or Gambit, both written in Scheme...)