Re: [Evolution-hackers] About the new camel_pstring_add implementation

[Philip Van Hoof <spam pvanhoof be>]

On Wed, 2006-07-12 at 10:17 -0400, Jeffrey Stedfast wrote:
> On Sun, 2006-07-09 at 13:04 +0200, Philip Van Hoof wrote:
> > These can be replaced with the new camel_pstring_add using FALSE as
> > parameter. Replacing them will also remove the need for the normal
> > camel_pstring_strdup and therefore also remove the need for the gboolean
> > own parameter of camel_pstring_add.
> 
> that's not actually true... the 'own' paramwter will still be required
> (I should probably rename that to 'take' or something tho, might make
> that clearer)
 
> > camel-folder-summary.c: to->subject = camel_pstring_strdup(from->subject);
> > camel-folder-summary.c: to->from = camel_pstring_strdup(from->from);
> > camel-folder-summary.c: to->to = camel_pstring_strdup(from->to);
> > camel-folder-summary.c: to->cc = camel_pstring_strdup(from->cc);
> > camel-folder-summary.c: to->mlist = camel_pstring_strdup(from->mlist);

Oh, right. Those are in the message_info_clone.

However, is it wrong to just use FALSE so that a cloned message-info
struct shares the memory with the original one, if the data is only
freed using camel_pstring_free? (freeing it with g_free is going to
cause havoc anyway, so I'm guessing this is already the case).

for example

CamelMessageInfo *new, *mi = existing();
gchar *str1 = g_strdup ("test1");
gchar *str2 = g_strdup ("test2");

mi->from = camel_pstring_add (str1, FALSE);
new = message_info_clone (mi);
new->from = camel_pstring_add (str2, FALSE);

g_free (str1); g_free (str2);

camel_pstring_free (new->from);
camel_pstring_free (mi->from);

Doesn't that just work?

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