Re: [Evolution-hackers] Removing libical fork, moving to new upstream?



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
--  
Patrick Ohly gmx de
http://www.estamos.de/



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]