My mistake, born from my lack of experience in using C.
I promise I'll stop after this, but if you're reasonably inexperienced in using C, I would highly encourage you to think about using a garbage collection scheme that way your time isn't spent hunting memory errors and is instead spent developing code. Performance is equiv, except you can rest with peace of mind knowing that you won't have any memory leaks or double free(3) errors. Explicit control over memory generally isn't even optimized.
So I go back to the code and make sure glists are more consistently filled with strings that have to be freed or not. Basically I'm just wrapping all the "no malloc" strings in g_strdup()-s whereever I suspect possible mixing. That way everything gets allocated memory. Seems like suboptimal somehow... any ideas ?
Experience tells me that if you're mixing const char *'s with char *'s in a list, you're going to be in for problems. strdup(3)'ing them is the accepted work around, however it begs the question of "is this the right way to solve the problem?" Basically I'm stumbling over a different way of saying, if it isn't elegant, then it probably ain't right.
Stick with strdup(3)'ing for now... with a database involved, I hardly imagine strdup(3) being a major contributor to any degradation of performance. Not to suggest it shouldn't be fixed more properly at some point in the future, but only to suggest that it's fine for now.
I'm dying without a stable IMAP server. :) -sc -- Sean Chittenden
