Re: [9fans] quantity vs. quality
- From: quanstro@xxxxxxxxxxxx
- Date: Sun, 11 Jun 2006 23:10:41 GMT
On Sun Jun 11 07:24:25 CDT 2006, lucio@xxxxxxxxxxxxxx wrote:
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.
i don't think this is about "trusting" somebody do do the right thing
for recovery.
if malloc's datastructures are corrupt, then you can assume that memory
is corrupt. somebody's fandangoed on core. since you don't have any
valid data, what can you accomplish except call sysfatal. (which might not
work.)
the most incidious bit about trying to recover when you're really and
truly hosed is that you just make debugging harder.
btw. glibc will abort if you corrupt the heap or double-free.
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.
i think you're reading me wrong. it's not about trust. it's about how
software really gets written. i'm as guilty as the next guy in writing
fancy recovery code that i never try out.
i've been bitten in production at least twice by botched recovery.
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.
yes.
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.
this is exactly why i think that sysfatal can be good if you really can't continue
or continuing is very likely to mask an error.
if you fail to get 20 bytes from malloc, for instance, it's likely you have an
huge leak in your program that needs to be fixed.
- erik
.
- References:
- Re: [9fans] quantity vs. quality
- From: lucio
- Re: [9fans] quantity vs. quality
- Prev by Date: Re: [9fans] drawterm configuration
- Next by Date: Re: [9fans] quantity vs. quality
- Previous by thread: Re: [9fans] quantity vs. quality
- Next by thread: Re: [9fans] quantity vs. quality
- Index(es):
Relevant Pages
|
