Hi Bob, On Thu, Dec 20, 2012 at 3:24 PM, Bob Friesenhahn <bfriesen@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, 20 Dec 2012, Jeffrey Walton wrote: >> >> If a project does not observe proper preprocessor macros for a >> configuration, a project could fall victim to runtime assertions and >> actually DoS itself after the assert calls abort(). The ISC's DNS > > The "falling victim to runtime assertions" is the same as falling victim to > a bug. It is not necessarily true that removing the assertion is better > than suffering from the unhandled bug. Once again this is a > program/situation-specific issue. Well, I can't think of a situation where an abort or crash is preferred over gracefully handling a failure that could be handled with an exit. In this case, the program is already in a code path - why not just fail the function rather than abort? But then again, I don't think like many others (as you can probably tell). So I could be missing something. In the case of a bug with known security implications (a detectable stack smash, for example), include a "last line" defense that ensures the program does not proceed (such as an OS initiated termination). There is a subtle difference: in one case the program is calling abort(); while in the other the OS is calling abort(). > You keep repeating standard recipies which are not proper/best for all > software. I understand its not "one size fits all," but I'm not proposing anything evolutionary either. All I ask is that a program properly handle its use cases (including negative cases). The program should exhibit well defined behavior (its an attribute or emergent property of being correct). Part of exhibiting well defined behavior is having an understanding of your tools due to things like Debug/Release and NDEBUG. Folks *have* to be responsible for their programs. They can't keep passing the buck and hope someone else will take care of it. The operating system or Distribution Maintainers should not have to do these things for developers. Jeff _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
