RaSPF on its way to release

2007-03-13 11:04

I have been able to work some more on RaSPF and the results are encouraging.

Thanks to valgrind and test suites, I am pretty confident it doesn't leak memory, or at least, that it doesn't leak except on very rare cases.

I think I found a neat way to simplify memory management, though, and that's what I wanted to mention.

This is probably trivial for everyone reading, but I am a limited C programmer, so whenever something works unexpectedly right, I am happy ;-)

One problem with C memory management is that if you have many exit points for your functions, releasing everything you allocate is rather annoying, since you may have to do it in several different locations.

I compounded this problem because I am using exceptions (yeah, C doesn't have them. I used this).

Now not only do I have my returns but also my throws and whatever uncaught throw something I called has!

Hell, right?

Nope: what exceptions complicated, exceptions fixed. Look at this function:

bstring spf_query_get_explanation(spf_query *q, bstring spec)
{
    bstring txt=0;
    struct bstrList *l=0;
    bstring expanded=0;
    bstring result=0;
    struct tagbstring s=bsStatic("");

    try
    {
        // Expand an explanation
        if (spec && spec->slen)
        {
            expanded=spf_query_expand(q,spec,1);
            l=spf_query_dns_txt(q,expanded);

            if (l)
            {
                txt=bjoin(l,&s);
            }
            else
            {
                txt=bfromcstr("");
            }
            result=spf_query_expand(q,txt,0);
            throw(EXC_OK,0);
        }
        else
        {
            result=bfromcstr("explanation: Required option is missing");
            throw(EXC_OK,0);
        }
    }
    except
    {
        if(expanded) bdestroy(expanded);
        if(txt) bdestroy(txt);
        if(l) bstrListDestroy(l);
        on (EXC_OK)
        {
            return result;
        }
        if(result) bdestroy(result);
        throw(EXCEPTION.type,EXCEPTION.param1);
    }
}

It doesn't matter if spf_query_expand or spf_query_dns_txt throw an exception, this will not leak.

Nice, I think :-)

Tomaz Canabrava / 2007-03-13 20:36:

I don't get the point. if try -> cath is the way to dont leak memory, why don't you use C++ , since it has build in try / catch instead of a c hack?

mix / 2007-03-13 20:46:

Exceptions seem a bit unC-ish to me... and it looks to me that the implementation you are using is not thread-safe.

Why don't you just use the "standard" approach:

int func(int a, int b)
{
int ret = SPF_ERROR;
resource *xa = make_res(a);
if(xa) {
resource *xb = make_y(b);
if(xb) {
... do something with xa and xb
if(everything ok) ret = SPF_OK;
destroy_y(xb);
}
destroy_res(xa);
}
return ret;
}

You can also add more specific error codes SPF_ERROR_{reason}.

jstaniek / 2007-03-13 20:53:

Hello, your web sidebar looks broken on Seamonkey...

Roberto Alsina / 2007-03-13 21:27:

mix: because it's an unreadable mess, and doesn't handle propagation of errors up the call chain, so you have to think of any error anything you call can ever produce?

Gotos are cleaner than that.

Tomaz: It would make even more sense to use D which has exceptions **and** garbage collection. But I wanted to do this particular project in C.

jstaniek: It should look ok if you make your window wider. That's a bug in my CSS but I haven't had time to hack around it.

mix / 2007-03-14 00:17:

It is the same thing as c++ destructors, just rewritten into c. When I "switch down" to c from c++, I continue using the same approach, it's probably a habit :).

I dislike jmpbuf based c hacks, I remember using libpng - now that is a mess. You have to create artificial barriers between APIs as an API user, because exception implementations differ. It is simpler to just handle ints, IMO. Pthread API is a good example of what I'm trying to say here.

Roberto Alsina / 2007-03-14 01:38:

Well, the idea here is that exceptions don't cross the boundaries of my library, and the underlying libraries don't use them (or at least I am not seing them ;-)

I suppose just like you can write Fortran on every language, I am writing some sort of perverse python in C ;-)

Tomaz Canabrava / 2007-03-14 02:49:

sure... but perverse python in c is not c. it's perverse python in c. and if you use try // catch in your 'c' code, anyone that get's the code and start looking at it will not see that's c, they will think that's c++. if you wish to do in c, do in c. also you should use try / catch only when it's really necessary, because it overloads the code, and make the program a little more bloated. but, still, this is just my humble opnion.

Roberto Alsina / 2007-03-14 11:23:

Tomaz: That's like the old argument about how Qt is not "real C++" because of moc.

I didn't buy it then and don't buy it now.

"Perverse python" is only a statement about style.

Ralsina.Me — Roberto Alsina's website