Ilja Booij wrote:
On Mon, 22 Nov 2004 14:32:40 -0800, Sean Chittenden <[EMAIL PROTECTED]> wrote:
This is mandatory. You can't ever not do that. In fact, I consider
it best practice to do the following:
I've run out of time to finish this, but, the attached patch starts to
bzero(3) all malloc(3) calls. I know this is overkill, but for the
time being, it's better to be safe than sorry. I'm alarmed at a few of
the calls in dbmail_imap_session_new(), however. Why on earth are we
malloc(3)'ing a char? The pointer is at least four bytes (depending
on your architecture), but the resulting allocation is only one byte.
Why bother at all? Why not just make self->tag a character instead of
a pointer?
self->tag = (char *)my_malloc(sizeof(char));
self->command = (char *)my_malloc(sizeof(char));
self->args = (char **)my_malloc(sizeof(char **));
I don't see how this code can be right.. self->tag and self->command
can both be more than 1 characters long. This looks like a bug in the
2.1 code.
I'll get on it, as soon as I have the imap-loop fixed. I think I'm on to
something, and I'm testing it on an installation that suffers from it as I write
this.
The idea I was trying above was to allocate in dbmail_imap_session_new, and in
all the setTag, setCommand, etc call, first free and then reallocate, and
finally free them all in dbmail_imap_session_delete.
But it doesn't work, I know... Just too busy on the 2.0 code to do much work on
the 2.1 codebase.
--
________________________________________________________________
Paul Stevens [EMAIL PROTECTED]
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands_______________________________________www.nfg.nl
