* Werner Koch: > On Sat, 11 Feb 2006 12:36:52 +0100, Simon Josefsson said: > >> 1) It invoke exit, as you have noticed. While this only happen >> in extreme and fatal situations, and not during runtime, >> it is not that serious. Yet, I agree it is poor design to >> do this in a library. > > I disagree strongly here. Any code which detects an impossible state > or an error clearly due to a programming error by the caller should > die as soon as possible. If you try to resolve the problem by working > around it will increase code complexity and thus error won't be > detected. (Some systems might provide a failsafe mechanism at a top > layer; e.g. by voting between independed developed code).
_exit in libraries is fine if you don't service multiple clients from a single process. However, with the advent of heavy VMs and stuff like that, there is a trend towards serving multiple clients from a single process (which is quite a bad idea in almost all cases, but this view is rather unpopular). There are also libraries which require proper cleanup procedures, otherwise the next program start can be quite costly (think of databases, where you want to avoid log replay). Some services have even been implemented following a single-process model for more than a decade (IRC servers, for example). A user-defined "fatal error" function (which must not return) would be a compromise, I think. Of course, such a function should never be called if you just see wrong or unsual input. But with a bit of optimism, the process could recover from an error which is not locally recoverable (throw an exception, terminate the offending thread, and leak the allocated resources). Now if the library maintains global, per-process state, this is a real problem. You can't know for sure if this state is consistent after a fatal error, unless you program carefully to avoid this situation. Yet another reason to move this functionality to a separate process. 8-) --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]