On Dec 2, 2006, at 11:59 PM, Mark Crispin wrote:

I have a two-line program which will crash any Mac OS X system.

Assuming that's userland code please report it at <http:// www.apple.com/macosx/feedback/>. Every Apple engineer I know consistently says that NOTHING in userland should be able to take down the kernel and this whole machine. The system should limit userland misdeeds to that process. If you have such a case, please report it so it can be fixed.

But this is not what we are talking about. We are talking about internal consistency checks. Linux, Windows, and Mac OS all panic when an internal consistency check in the kernel detects corruption in the data structure. None of these kernels proceed if they detect that they have been hosed.

I certainly agree here that detecting and logging an error earlier is better. Having code plow ahead and crash later is not helpful, as we've likely all found.

While I can see the point that an app that just aborts without the ability to show the user a description of the problem is sub-optimal, it's not fair to fault c-client in this regard. In my experience it goes to great pains to not do additional damage when unexpected errors occur. I find that laudable. Would that all my other software would be so considerate. I'd prefer an app that aborts to one that forges forth and corrupts my data files.

As to the malloc() failure handling, Mark's defined the c-client interface consistently. If an OS error ends up causing a c-client- based app to abort when an error occurs then fine. If an app on any of my Unix systems were to fail due to a malloc returning NULL it would indicate errors well beyond just that process.

I think that was one of Mark's points. If you actually have an app suffer a failed malloc call on a modern OS then there something broadly wrong that can't really be fixed or handled by that app. The best it can do in such a case is fail without contributing to or propagating the failure.

As to the more personal attack, that's been addressed already.

-Mike

_______________________________________________
Imap-uw mailing list
Imap-uw@u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

Reply via email to