[CF-Devel] Bug in stealing code

[crossfire-devel at archives.real-time.com]

Andreas Kirschbaum wrote:

>
     
     
     >
     
     
     >
     
      OK, will declare it as a macro in define.h.
     
     >
     
     
     >
     
      The reason for using a function is that I generally tend to avoid
     
     >
     
      macros: when calling a macro, you have to worry about side effects
     
     >
     
      (due to possible multiple evaluations of parameters) and also do
     
     >
     
      not get type-checking by the compiler.
     
     
  I agree in principal.  However, in this particular case, it is pretty clear 
there won't be any side effects (we aren't doing assignments).


>
     
     
     >
     
      Java exhibits this limited usefulness that you have to explicitly
     
     >
     
      enable assertions (at runtime). The behavior of C assertions is
     
     >
     
      exactly the opposite: the C standard says (in section 7.2):
     
     >
     
     
     >
     
      |If NDEBUG is defined as a macro name at the point in the source
     
     >
     
      |file where <assert.h> is included, the assert macro is defined
     
     >
     
      |simply as
     
     >
     
      |
     
     >
     
      |#define assert(ignore) ((void)0)
     
     >
     
     
     >
     
      That is, assert() does nothing *only if* NDEBUG ("no debug") is
     
     >
     
      defined. Otherwise (i.e. if you do not explicitly disable the
     
     >
     
      assertions by defining NDEBUG), the assertions are active.
     
     
  Yeah, I see that - nice use of double negatives to make it more confusing.


>>
     
     And if it is a critical error, to the extend that trying to
     
     >>
     
     continue will just cause it to core dump in the next line or
     
     >>
     
     two, might as well call abort right then and there.
     
     >
     
     
     >
     
     
     >
     
      These are the types of errors that should be checked with
     
     >
     
      assert(): to detect an inconsistent internal state that should
     
     >
     
      never be possible. Therefore assert() prints an error message to
     
     >
     
      stderr and calls abort() if it fails.
     
     
  I guess it's OK.  The usefulness really depends on a few things:
1) Will the asserts reduce reliability (eg, cause aborts where without the 
assert, the code would still execute OK)
2) adversely effect performance - in this particular case, I don't see a 
problem, but one could see adding asserts in code that is caused really often 
not useful.
3) will it assist in debugging the code.

  Basically, does having them do more good than harm.  Note however it may 
(depending on the function) be useful to have actual LOG messages that can print 
out lots of debugging info before actually crashing (ala the aborts in 
common/object.c)


_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel