On Tue, May 05, 2009 at 11:38:36PM +0000, David Holland wrote: > On Wed, May 06, 2009 at 12:33:00AM +0100, Alistair Crooks wrote: > > Imagine someone embedding this library in their (embedded) product. > > Having the library dump core for what is an unusual ocurrence, admittedly > > (such as an out of memory condition, perhaps) is suboptimal, since the > > product may then have to be re-started to get a working system. This > > is too intrusive. As someone with an LCD TV which sometimes does this, > > it annoys me intensely. Names and models on request, in private. > > > > This also brings us round to a pet peeve of mine - for development > > work, dumping core is fine for exceptional conditions. Same as kernel > > panics. It's not usually wanted in production code. > > Having things fail silently or go into a fugue state is not an > improvement, particularly in security code. So I'd qualify all this by > saying that end-to-end behavior should always be fail-stop. > > However, I'm inclined to agree that libraries should not in general > abort on behalf of an application, and that it's the application's > responsibility to be fail-stop.
So, as far as the library is concerned, shouldn't these assertions be preserved, and face conversion to _DIAGASSERT(3)? - Klaus
