[m-dev.] Re: for review: software errors from C code

[Andrew Bromage]

G'day all.

Tyson Richard DOWD wrote:

> >Index: library/io.m
> >===================================================================
> >RCS file: /home/staff/zs/imp/mercury/library/io.m,v
> >retrieving revision 1.153
> >diff -u -r1.153 io.m
> >--- io.m	1998/03/12 19:45:38	1.153
> >+++ io.m	1998/03/26 05:19:49
> >@@ -2187,7 +2187,7 @@
> > 	}
> > 	/* XXX should work even if ungetc() fails */
> > 	if (ungetc(Character, mf->file) == EOF) {
> >-		fatal_error(""io__putback_char: ungetc failed"");
> >+		software_error(""io__putback_char: ungetc failed"");
> > 	}
> > 	update_io(IO0, IO);
> > }").
> 
> This doesn't fit into your defintion of "user-fixable" errors above.
> This is in fact an implementation weakness.  Some of the other ones are
> similar.

It sort of is and it sort of isn't.  Yes, it's an implementation
weakness (which I think Fergus agrees with me in that it shouldn't
be fixed until we have streams implemented as typeclass because of
the overhead).  However it is user-fixable to some extent --- you
can implement putback_char yourself or not rely on it so much. :-)
In any case, the stack dump is useful here.

BTW, I originally called software_error `fatal_error_and_dump_stack',
but that was a bit misleading.  Perhaps the right solution here is to
pass in a "do a stack dump" flag?

Probably what we _should_ do is make this an error which says,
"we'll get around to fixing this sooner or later" or other
appropriate words.

> >+** XXX checked_malloc() and checked_realloc() should be moved to
> >+**     mercury_memory.h or mercury_heap.h
> 
> Why not do it now?  It looks like the only way the runtime is going to
> be cleaned up is if we do it piece by piece as we make other changes.

I was just thinking that, actually.  mercury_memory seems the best
choice since malloc() and realloc() don't allocate on the Mercury
heap.

At any rate, as I said earlier, the next version of this diff will wait
until Zoltan's latest changes are committed.  (Though moving
checked_malloc() is relatively independent --- I might do that now.)

Until then, thanks for the review.

Cheers,
Andrew Bromage