Hi all,

The assert() discussion seems to have taken place a few times
now, but I still feel the need to vent my thoughts on the
matter.

To get one thing out of the way beforehand: asserts have no
meaning in production builds. They are simply not compiled in
[well, they become noops].
The same goes for symbols, effectively rendering a coredump
useless. So lets talk about debug builds and the groups of
programmers, the APR programmers and the application programmers
(ie. the APR users).

Then I need to tell something about my background. I work on
multiple platforms, two of them being Windows 2000 and Linux.
I use MS Visual C++ on windows and this has gotten me being 
spoilt. When running an application in debug mode and testing
it by using it like a user would, an encountered assert brings
up the visual debugger on the line of the assert and halts the
application there. When this happens I usually know instantly
what I forgot to do [so this is from the 'app programmers'
point of view].

To wrap the assert subject up I'd like to say that I, personally,
like asserts because they allow me to let the code bomb out
in a (semi)controlled way in debug time. Whereas in production
the code simply bombs out 'uncontrolled'. This seems a minor
difference, but it is easier to debug [why were asserts invented
in the first place if this wasn't the case? I have the feeling
someone is going to smack me on the head with a history book on
that one :-) ].

Finally: what is the general feeling about asserts?

On to policy. These last few hours I ran into a 'policy violation'.
I used the following construction somewhere *):

apr_status_t some_apr_func(some_type *pointer_argument)
{
    if (!pointer)
        return APR_EINVAL;

    ...

}

I thought this would be good conduct because APR is a library
and should report errors to the application (the user) instead
of bombing out. I agree that this is unneccesary bagage in a
production environment with decent tested/debugged applications.

But what about the testing/debugging phase? The APR library is
probably built with debug flags turned on full in this phase.
Should the code still segfault?

Anyhow, if the policy is segfaulting when passing a NULL pointer,
lets segfault. However, lets document this policy somewhere, so
new apr/patch developers know about it and can adopt the policy.
Ofcourse the review system filters out a lot of this stuff, but
I wonder if the entire APR team knows about the policy.

If there already is a document describing this policy please
provide me with a pointer to it. Maybe a link on the APR development
pages isn't such a bad idea either. If such a document doesn't
exist it is probably wise to put one together. Preferably someone
who is familiar with the policy and 'correct' APR coding style.


Just my opinion on this,

Sander


*) this time it was in apr_md4.c, but it is plastered all over the
   sms code aswell. I wonder if this check is valid anywhere?

PS. Sometimes my english is a bit crude, this is caused by the fact
    that english isn't my native tongue. So, if it is the language
    that ticked someone of, please don't be :-)