apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject Re: APR, asserts, policy
Date Mon, 04 Jun 2001 23:19:13 GMT
On Tue, 5 Jun 2001, Sander Striker wrote:

> 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?

I see a use for them... but checking NULL pointers isn't usually it IMHO.
As I see it, an assert() is good if you want to test for some non-trivial
condition that wouldn't result in a segfault (at least not right away),
but is nevertheless really, really bad.  Assertions for NULL pointers are
okay IMHO if the pointer isn't going to be deref'ed right away (ie, no
immediate segfault), but the pointer still shouldn't ever be NULL.

In any other case (ie, any case where you can skip the assert and still
get a coredump right away), you don't need an assert().  That's my take,
and I *think* it echos the feelings of many people here.

> 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've had that feeling myself.  But in the end I'm forced to agree that
it's better to segfault than to just return an error... as Jeff said, if
the caller couldn't manage to pass us a non-NULL pointer, they probably
aren't going to bother checking our return code.  That could make for a
really tough debug in some situations.

> 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.

Fine by me.

> Ofcourse the review system filters out a lot of this stuff, but
> I wonder if the entire APR team knows about the policy.


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

I honestly didn't notice.  =-)

Anyway, I've just committed a biggish patch to SMS that removes all of the
parameter checking, extraneous asserts (ie, ones where the code would
segfault right away anyhow), and fixed a bug which caused
apr_sms_assert() to never be compiled.  Do me a favor and look it over.
If you feel I've removed too much, just say so and I'll put it back.


   Cliff Woolley
   Charlottesville, VA

View raw message