Bill Studenmund <wrstuden@NetBSD.org> writes:

> Uhm, I don't remember saying I don't want core dumps. They can be VERY 
> valuable. However I don't want a core dump to tell me I had a crash in an 
> error-handling log message. A core telling me I had a crash in code 
> handling a case I _should_ be handling (or should be protecting against), 
> that's fine.

How does printf() distinguish when it's being called to print a log
message and when it's being called, say, to generate normal
application output? It doesn't. Not coring in the error situation is
very much a special-case desire.

> I'm still not getting how printf() or puts() not coring is incorrect 
> behavior. The strongest I've heard so far is that the behavior is 
> undefined and up to the implementation. I have not heard a requirement 
> that the implementation has to crash. Yes, I do agree that a program 
> operating in a standardized environment (-std=<foo> or -ansi or such) 
> should not ASSUME that it can do it, but I haven't heard someone quote 
> that we MUST crash.

I don't think anyone is arguing that we are REQUIRED to crash, merely
that it's a BETTER IDEA than not crashing. The term of art that I
would apply here is "fail-fast": when the application's state is
corrupted, it should crash as soon as possible, so as to make the
crash closest to the corruption and prevent any further corruption of
data.

        - Nathan