On Mon, 28.10.13 21:07, Tom Gundersen ([email protected]) wrote:

> 
> On Mon, Oct 28, 2013 at 8:33 PM, Lennart Poettering
> <[email protected]> wrote:
> > On Mon, 28.10.13 20:30, Tom Gundersen ([email protected]) wrote:
> >
> >>
> >> On Mon, Oct 28, 2013 at 6:54 PM, Lennart Poettering
> >> <[email protected]> wrote:
> >> >> +struct link_config_ctx {
> >> >> +        LIST_HEAD(link_config, links);
> >> >> +
> >> >> +        char **link_dirs;
> >> >> +        usec_t *link_dirs_ts_usec;
> >> >> +};
> >> >
> >> > Maybe define a local _cleanup_ macro here?
> >> >
> >> > _cleanup_(link_configs_freep)?
> >>
> >> Hm, I don't follow. Where could this macro actually be used?
> >
> > In the _new() allocator I thought? Or no?
> 
> Hm, wouldn't the new object (ctx) unconditionally be freed when _new()
> returns, even if we do "*ret=ctx ; return 0"? Or am I misunderstanding
> how this stuff works?

Yes it would. So it's your choice: whether to free explicitly, or
whether to free implicitly. In the latter case you have all the code for
the freeing in there, in the former case you'd have to explicitly reset
ctx = NULL afer assigning it to the return value...

It usually boils down to what you personally prefer or maybe which
version would be longer...

Lennart

-- 
Lennart Poettering, Red Hat
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to