On Mon, 2008-09-08 at 12:16 -0400, IGnatius T Foobar wrote: > In what way does it break the userspace API? Is it possible that the > API could be extended in such a way that memory handling depends upon > how it's called?
Chenthill already provided the relevant links: http://bugzilla.gnome.org/show_bug.cgi?id=516408 http://bugzilla.gnome.org/show_bug.cgi?id=528986 For the sake of discussion let me summarize how the API has changed, then suggest ways how that could be dealt with. In the upstream libical certain functions return char * pointers into memory stored in ring buffers. The caller must not free those pointers. The drawback is that the life time of those strings is not predictable. In the current Evolution libical, those same functions (not renamed!) return copies of the string which the caller has to free. Code which was written using the old semantic of the calls will leak memory. Code adapted to the new semantic (like Evolution) will crash when combined with the upstream libical without the same patch. There are defines in the Evolution libical header which can be used to detect what the memory handling is, so code can be written so that it works with both the old and the new semantic. SyncEvolution goes one step further and also does a runtime check, so the same binary works with both an old and a new Evolution release. If all users of the upstream libical are willing to adapt their code, then the best solution would be to simply import the Evolution patch into upstream. If there is resistance against that, then we could provide two versions of each of these API calls: one with the old name and old behavior and one with the new behavior and a name suffix. Evolution then has to be patched to use the new calls, which can be done either with a global search/replace or via defines (ugly!). SyncEvolution would work fine without code changes, it'll simply fall back to not freeing the strings. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ _______________________________________________ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers