[libvirt PATCH 04/19] commandhelper: Consolidate error paths

Peter Krempa pkrempa at redhat.com
Fri Jan 29 18:06:06 UTC 2021


On Fri, Jan 29, 2021 at 17:52:35 +0000, Daniel Berrange wrote:
> On Fri, Jan 29, 2021 at 06:17:36PM +0100, Peter Krempa wrote:
> > On Fri, Jan 29, 2021 at 17:16:14 +0100, Tim Wiederhake wrote:
> > > Preparation for later conversion to g_auto* memory handling.
> > > 
> > > Signed-off-by: Tim Wiederhake <twiederh at redhat.com>
> > > ---
> > >  tests/commandhelper.c | 10 ++++++----
> > >  1 file changed, 6 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/tests/commandhelper.c b/tests/commandhelper.c
> > > index 05e3879688..2be121ce2c 100644
> > > --- a/tests/commandhelper.c
> > > +++ b/tests/commandhelper.c
> > > @@ -61,7 +61,7 @@ int main(int argc, char **argv) {
> > >      ssize_t got;
> > >  
> > >      if (!log)
> > > -        return ret;
> > > +        goto cleanup;
> > >  
> > >      for (i = 1; i < argc; i++) {
> > >          fprintf(log, "ARG:%s\n", argv[i]);
> > > @@ -79,7 +79,7 @@ int main(int argc, char **argv) {
> > >      }
> > >  
> > >      if (!(newenv = malloc(sizeof(*newenv) * n)))
> > > -        abort();
> > > +        goto cleanup;
> > 
> > Any reason for not converting this malloc to g_new directly? you get rid
> > of abort()/cleanup entirely.
> 
> commandhelper isn't permitted to link to glib, because we need a clean
> execution environment for counting FDs.
> 
> > 
> > Especially since the patches at the end of the series switch to
> > g_auto(ptr).
> > 
> > If there's a strong reason against using glibs allocators, in such case
> > the cleanups shouldn't be added either.
> 
> We get away with the g_auto usage because its merely a macro

Hmm, yeah. It looks a bit weird though.




More information about the libvir-list mailing list