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.