On Sun Jun 11 07:24:25 CDT 2006, [EMAIL PROTECTED] 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
