Re: ECalComponentAttendee and ECalComponentOrganizer - an invitation to memory leaks?

Chenthill <[email protected]>
Newsgroups gmane.comp.gnome.evolution.devel
Message-ID <1150435670.6657.6.camel__5919.10652951828$1150482145$gmane$org@chenthill.blr.novell.com>
Hi Jules,

On Wed, 2006-06-07 at 14:41 +0200, Jules Colding wrote:
> Hi,
> 
> Several members of the above mentioned structures are of the 'const char
> *' type. One such member is 'value'.
> 
> The message from the API designer, when declaring something 'const char
> *', is commonly that the memory management of that parameter/member is
> the responsibility of whoever allocated the memory.
Yes, the memory for the members such as "value" is managed inside the
ECalComponent itself. The caller need not allocate the memory.
> 
> The usage of ECalComponentAttendee and ECalComponentOrganizer data
> structures in e-d-s is, OTOH, that they are given to some ECalComponent
> and are never touched by the callee again (unless I am totally wrong
> here).
> 
> So should data for e.g. the 'value' member be g_strdup'ed to 'value' (as
> does the Groupwise calendar backend) contrary to the expectation that
> the callee should manage the memory for that member?
Groupwise backend does it wrongly which needs to be fixed. Thanks for
pointing it out.


thanks, Chenthill.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.