[freetds] tdoParseConnectString

Frediano Ziglio freddyz77 at tin.it
Thu Apr 3 15:13:40 EST 2003


> 
> > Personally I don't like assert that much. 
> 
> Why?  
> 

My background is DOS (not DoS :) ), Windows, Linux ... for O/S and
BASIC, Pascal, ASM, (C), C++ ... for language. I like performance and I
prefer the use of assert in DOS/Windows. In DOS/Windows assert are
disabled by default while in many Unix programs assert are enabled by
default. 
This is why I don't like assert that much.

> > It should be removed from final
> > compile. I think we should define another macro based on
> > --enable-extra-checks instead of enabling always assert...
> 
> The assert() macro *is* removed in the "final" compile, if NDEBUG is
> defined, at least on my system.  
> 
> Assert is your friend.  It provides information that segment faults don't.
> It's a strong comment in the code about the programmer's assumptions.  It
> avoids the need to backtrack a runtime fault stemming from a bad assumption.
> 

When I write programs sometimes I fill them of assert (one of my program
is 4 time slower compiled with assert enabled...). 

Also I saw assert code like
  char *p = (char*)malloc(10);
  assert(p);
(good for practice but not for real programs...)

In another program I defined two macro:

PRG_ASSERT and COMPILE_CHECK. I use my PRG_ASSERT instead of assert
cause PRG_ASSERT is disabled by default. COMPILE_CHECK is a macro to do
tests are compile time... if you think is useful for FreeTDS here you
are:

#if defined(__GNUC__) && __GNUC__ >= 2
#define COMPILE_CHECK(name,check) \
    extern int name[(check)?1:-1] __attribute__ ((unused))
#else
#define COMPILE_CHECK(name,check) \
    extern int name[(check)?1:-1]
#endif

freddy77




More information about the FreeTDS mailing list