pspp-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: assert vs. abort


From: John Darrington
Subject: Re: assert vs. abort
Date: Sun, 2 Apr 2006 07:12:23 +0800
User-agent: Mutt/1.5.4i

On Sat, Apr 01, 2006 at 11:16:42AM -0800, Ben Pfaff wrote:
     
     >      How about this:
     >      
     >          ASSERT() -- for cheap, important checks
     >          ASSERT1() -- for more expensive or less important checks
     >          ASSERT2() -- for expensive checks
     >          ASSERT_LEVEL -- if defined to a number, checks at the given
     >          level or higher are disabled.
     >          NOT_REACHED() -- as discussed
     >
     >
     > I'd be reasonably happy with that.  presumably ASSERT{,1,2} simply
     > call ASSERT_LEVEL.  And you might want to change 1 & 2 to symbols,
     > that way, we can insert a level between 1 and 2 at a later stage if we
     > find it becomes necessary.
     
     I meant that ASSERT_LEVEL would be analogous to NDEBUG.
     Something like this:
     
         #ifndef ASSERT_LEVEL
         #define ASSERT_LEVEL 1              /* or whatever default we want */
         #endif
     
         #if ASSERT_LEVEL > 2
         #define ASSERT2(EXPR) ASSERT_CHECK(EXPR)
         #else
         #define ASSERT2(EXPR) ((void) 0)
         #endif
     
         #if ASSERT_LEVEL > 1
         #define ASSERT1(EXPR) ASSERT_CHECK(EXPR)
         #else
         #define ASSERT1(EXPR) ((void) 0)
         #endif
     
         #if ASSERT_LEVEL > 0
         #define ASSERT(EXPR) ASSERT_CHECK(EXPR)
         #else
         #define ASSERT(EXPR) ((void) 0)
         #endif

Doesn't this still leave a problem if we want to add a level between 1
& 2 ?  I would perform the following sedscript on the above.
s/ASSERT1/ASSERT_EXPENSIVE/
s/ASSERT2/ASSERT_VERY_EXPENSIVE/ 
s/\ 1/\ 10/
s/\ 2/\ 20/

     
     > The question remains then, what level of assertions should be enabled
     > when?  
     >
     > * I suppose for development all assertions are enabled?
     >
     > * Do we want to turn off some/all ASSERTs when doing make dist ?  If
     >   so, then we'd have to hack the automake rules, to set the relevant
     >   assertion level and do a clean rebuild.
     
     The problem is distinguishing development from deployment.  I
     guess make dist would be one way.  But I think it might be
     cleaner to just default to some reasonable assertion level
     (probably 1 or 2) and then allow developers to override it with a
     make flag.


So long as the default is the level we want to deploy with, then this
should be OK.

     
     > * NOT_REACHED should *always* be enabled.
     
     ...though I'd argue that it should just expand to abort() when
     all assertions are otherwise disabled.

I'd have to respectfully disagree.  Our "You have discovered a
bug...." message has brought a number of bug reports which I believe
would otherwise have gone unreported.  Many people won't take the
effort to report a bug if the program just terminates with the rather
concise message "Aborted".


     > * Some systems I've seen have allow the assert/debug/log level to be
     >   set at runtime (through a config file).  Further, some allow  a
     >   "domain" flag in addition to  the level (eg {PARSER,OUTPUT,DATA
     >   etc}).    Although the   complexity of such systems usually means
     >   that most developers don't  understand how to use them, so they
     >   either avoid using it, or else they misuse it and thus render it
     >   useless for the few people who actually do know how to use it
     >   properly. 
     
     I'd like to avoid extra complexity until it's demonstrated to be
     useful.

I guess I would have to agree here.


J'

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.


Attachment: pgpvl8o2lP_W_.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]