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 :-)
