[libvirt] [PATCH] uml_conf.c: don't return an uninitialized pointer
Daniel P. Berrange
berrange at redhat.com
Thu Sep 3 10:49:42 UTC 2009
On Thu, Sep 03, 2009 at 12:43:10PM +0200, Jim Meyering wrote:
> Daniel P. Berrange wrote:
>
> > On Thu, Sep 03, 2009 at 12:07:14PM +0200, Jim Meyering wrote:
> >> Another "real" bug:
> >>
> >> >From 6697607bf0b023ffb692576b31d652d10719b08a Mon Sep 17 00:00:00 2001
> >> From: Jim Meyering <meyering at redhat.com>
> >> Date: Thu, 3 Sep 2009 12:05:52 +0200
> >> Subject: [PATCH] uml_conf.c: don't return an uninitialized pointer
> >>
> >> * src/uml_conf.c (umlBuildCommandLineChr): Initialize "ret" also
> >> in the final switch cases.
> >> ---
> >> src/uml_conf.c | 1 +
> >> 1 files changed, 1 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/src/uml_conf.c b/src/uml_conf.c
> >> index 838fedd..2e9c25c 100644
> >> --- a/src/uml_conf.c
> >> +++ b/src/uml_conf.c
> >> @@ -331,6 +331,7 @@ umlBuildCommandLineChr(virConnectPtr conn,
> >> default:
> >> umlReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR,
> >> _("unsupported chr device type %d"), def->type);
> >> + ret = NULL;
> >> break;
> >> }
> >
> > I think this would be better changing the initial declartion to be
> > initializing to NULL too.
>
> Actually I did that first, but then un-did it in favor
> of the change above. Why? because that initialization could
> mask a failure to initialize in a new case.
>
> With per-case initialization, we'd detect the bug at
> compile/static-analysis time. With the up-front unconditional
> initialization, we cannot, and would have to rely on testing to find it.
It is a tradeoff, but I still prefer the initialization at time of
declaration as a safety net, and we do use this pattern pretty much
everywhere
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
More information about the libvir-list
mailing list