Luke Mewburn <lukem@cs.rmit.edu.au> writes:
> i think this is a good idea, and unless it breaks standards, we should
> do it. of course, people will complain about the performance hit and
> the method of highlighting failure, so i suggest that the following
> be done:
> 	* all of this code would be #ifdef LIBC_DIAGNOSTIC
> 	* have diagnostics one of:
> 		- warn()
> 		- syslog "function __file__ __line__ ..." (my preferred ;)
> 		- nothing

what's the purpose of these messages?

is it to tell the system manager that a binary is bogusly coded?
who's to say that they _want_ to know whether a random binary that a
user compiled is bogus?  who's to say that the user wants the system
manager to know about things like this?

is it to tell a user that their program crashed because the developer
of the program was a bozo, rather than because the system was flaky?
what if they're not watching, or what if the application is such that
they'd never even see the message?

is it to provide a developer with feedback so that they can get
diagnostic information about a a problem that they can't reproduce?
the problem with any of these is that it may tell you which assertion
you've hit, but it won't tell you anything about the caller, etc, so
the debugging utility is useless.


> 	* have the failure mode one of:
> 		- return from function a failure code, but continue on
> 		- exit(1)
> 		- dump core using abort() (my preferred ;)

abort() is probably the only correct answer here, actually.

returning failure: no, it wasn't a 'failure' it was a programming
bug.  if you simply return failure, you make it that much harder to debug.

exit(1): who's to say that that won't have some wacko interaction with
the programmer's convention for use of exit codes?  i.e. exit(1) may
mean one type of failure, exit(2) may mean another, etc.



Before you go off and try to solve the problem, i think you have to
figure out which problem you're trying to solve.  8-)


FWIW, As a general purpose solution, i think the only one that works
is:
	* abort(), and
	* attempt to train software developers to catch and print
	  useful messages on abort() calls, if user notification
	  is desirable.


cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.