From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <73b6022509d05ce122618716e1a3f617@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] quantity vs. quality
Date: Sun, 11 Jun 2006 14:00:08 +0200
From: lucio@proxima.alt.za
In-Reply-To: <21a6ad2fac6f661265f32a015d5d5de6@quanstro.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 688d22fe-ead1-11e9-9d60-3106f5b1d025

> never?  what if malloc's datastructures are corrupt?

As long as the stack isn't corrupt, it _can_ still return to the
caller.  The argument is really whether the caller can be trusted to
take the correct (non)recovery action.  But you can't take away
Lucho's options because another 99 callers are too lazy.  Your view,
if I read you correctly, is that Lucho also can't be trusted, because
he won't test his recovery code, but that is not an acceptable
assumption.

Yes, we do need a middle ground and redefining _sysfatal() is one
option, but encouraging good programming practice, by example as well
as by instruction, would be preferable to unpredictable behaviour
under error conditions.

To me, the greatest loss in this age of complexity, is the determinism
of early day computing.  Anything that increases determinism at the
application level is to be encouraged, not discouraged.

++L

PS: What is true is that the Plan 9 developers did not have the
resources to do everything perfectly and picked sensible places where
this shortcoming would affect the result in the least destructive
fashion.  What is also true is that as a community we ought to be able
to improve on this, rather than concentrate on wild goose chases.
Which brings us back, full circle, to the desirability of GCC/G++ for
Plan 9.  Thanks, Latchesar :-)