On Thu, 2006-02-16 at 14:55 +0100, Jules Colding wrote:
> Hi,
>
> I am seeing up-source Camel code accessing and using memory previously
> freed.
Source and RPMs for the curious:
http://www.omesc.com/content/downloads/dist/SOURCES/evolution-brutus-0.9.4.tar.gz
http://www.omesc.com/content/down
Hi,
I am seeing up-source Camel code accessing and using memory previously
freed. The scenario is:
1) My provider implementation of delete_folder() is invoked.
2) The code goes something like this:
brutus_delete_folder(CamelStore *store,
const char *folder_name,
On Tue, 2006-02-14 at 11:22 +, michael meeks wrote:
> Hi there,
>
> So - I was pleased to see that the libebook .so remains unchanged from
> evo 2.4 to 2.6 - and I just did a little review to try to ensure that
> this indeed reflects an unchanged ABI ;-)
>
> It seems that is the c
On Wed, 2006-02-15 at 10:37 -0500, Jeffrey Stedfast wrote:
> CamelStore::free_folder_info()'s v.method can be overridden, so it's
> really up to your CamelStore implementation.
>
> The consumer of the ::get_folder_info() API is supposed to
> call ::free_folder_info(), but since it can be overridde
On Wed, 2006-02-15 at 12:11 +, michael meeks wrote:
> So,
>
> At the risk of offending the gender-confused; it would be -extremely-
> useful to have a Gender boolean in the evolution addresbook [ of course,
> perhaps there is & I'm just missing it but I dug into the code ].
No. There i
