TnyFolderMonitor infrastructure in place and working

[Philip Van Hoof <spam pvanhoof be>]

The TnyFolderObserver and TnyFolderMonitor infrastructure is now
operational in that that it can already add dummy headers.

Such a dummy header is indeed added if you compile the tny-camel-
folder.c file with a #define IM_TESTING or -DIM_TESTING flag at the
compiler line (export CFLAGS="-DIM_TESTING" before building).

This code is, indeed, for testing purposes.

I'm now implementing the bits in camel-lite to actually get meaningful
latest summary items (in case new ones where put in the active folder).

And after that, melting the pieces together should implement the
feature.

http://tinymail.org/trac/tinymail/wiki/WhenNewMessagesArrive


An important bug has been fixed in camel-folder-summary.c, the
camel_message_info_new used the wrong size to allocate the instance in
case the s parameter of the function was NULL.

This of course caused a bunch of extremely strange memory corruption
bugs. Which aren't that strange after looking at that it:

o. CamelMessageInfo is a dummy struct that is smaller than the real,
it's just there to present the offsets of the first members of
CamelMessageInfoBase. That's why the real size of each being allocated
is different from sizeof (CamelMessageInfo) but usually near (never
smaller than) the size of CamelMessageInfoBase.

It's larger in case the provider's CamelMessageInfo instances have extra
information that the normal one doesn't have. Sometimes this is the
case. That's why the Camel people did this allocation trick (to add more
members to the instance in case of overriding).

With NULL as argument, the sizeof(CamelMessageInfoBase) was suppose to
be used, the sizeof(CamelMessageInfo) was, however, used in camel-lite's
version of the function. Returning a much smaller instance, that was
being casted to CamelMessageInfoBase all over the place.

In other words .. each time members of the instance where written, other
memory was overwritten (because the offsets of CamelMessageInfoBase
where often further-away from the root than the size of the simpler
CamelMessageInfo structure).


Why is this related to adding summary information? Because adding
summary information starts with creating one item, with that "s"
parameter set to NULL (which triggered this bug).



-- 
Philip Van Hoof, software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://www.pvanhoof.be/blog