Re: glibc segfault on "special" long double values is _ok_!?

[Jeremy Linton <jli at greshamstorage dot com>]

> It may well be that the current glibc behavior is not prohibited by
> any standard, but I think that "quality of implementation" concerns
> (not to mention a desire for robustness and security) would dictate a
> more manageable result.

	Your right, it would seem that if its possible to make a fix that 
avoids a crash, even when that crash is caused by incorrect behavior in 
the application, its the right thing to do. I do it all the time in our 
application in response to user errors, hardware errors, other library 
programming errors. Frankly, in our application any crash is 
unacceptable.  Apparently that level of quality isn't a requirement for 
glibc. I understand that its impossible to close all the holes but when 
its an easy fix, I simply don't understand why the library cannot do it 
instead of having every application vendor have to provide wrappers 
around glibc functions to assure that error conditions that should be 
caught by the library are caught and handled before calling the library. 
 The current stance just makes glibc appear brittle.



	From monitoring this mailing list for a while it appears apparent that 
certain people pride themselves in rejecting any patch which improves 
the robustness of glibc.