Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
- From: "IGnatius T Foobar" <ajc citadel org>
- To: Patrick Ohly <Patrick Ohly gmx de>
- Cc: IGnatius T Foobar <ajc citadel org>, Wilfried Goesgens <dothebart uncensored citadel org>, Evolution Hackers <evolution-hackers gnome org>
- Subject: Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
- Date: Mon, 08 Sep 2008 23:55:22 -0400
Patrick Ohly wrote:
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.
Ok, I definitely see the benefit there. This is similar to POSIX calls
which now offer alternative versions (usually with "_r" appended to the
name) that don't use a static buffer or a ring buffer, in order to be
reentrant?
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.
As much as I'd like to see that happen, I don't think it's realistic.
libical is used by dozens of downstream projects, and a sudden forced
API change is likely to encourage them to fork (or stay forked, if
they've already done so) -- exactly the opposite of the end we are
trying to achieve!
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.
That seems more realistic. The alternative might be to offer a global
flag that tells libical to behave one way or the other? (I think
something like that was suggested at some point.)
While I definitely think the new method of memory allocation makes far
more sense (we'll definitely use it in Citadel, as all of our code is
multithreaded) -- expecting the entire community to perform a "flag day"
API change in lockstep is likely to cause confusion and delay. If we
pursued either the alternate function names or the global flag, is there
likely to be any pushback from the Evolution team?
-- Art
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]