[libvirt] [PATCH] initialize pointer to NULL
From 577ac7e8594cbcccb59653786e80c3916a3238cb Mon Sep 17 00:00:00 2001 From: Wen Congyang <wency@cn.fujitsu.com> Date: Sat, 2 Jul 2011 06:41:18 +0800 Subject: [PATCH] initialize pointer to NULL
def and cmd is not initialized to NULL, but we try to freed it if we meet some error. It's very dangerous. --- src/qemu/qemu_command.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 90a6653..6c78161 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -5818,7 +5818,7 @@ virDomainDefPtr qemuParseCommandLine(virCapsPtr caps, const char **progenv, const char **progargv) { - virDomainDefPtr def; + virDomainDefPtr def = NULL; int i; int nographics = 0; int fullscreen = 0; @@ -5827,7 +5827,7 @@ virDomainDefPtr qemuParseCommandLine(virCapsPtr caps, const char **nics = NULL; int video = VIR_DOMAIN_VIDEO_TYPE_CIRRUS; int nvirtiodisk = 0; - qemuDomainCmdlineDefPtr cmd; + qemuDomainCmdlineDefPtr cmd = NULL; if (!progargv[0]) { qemuReportError(VIR_ERR_INTERNAL_ERROR, -- 1.6.5.2
On 07/02/2011 08:55 AM, Wen Congyang wrote:
From 577ac7e8594cbcccb59653786e80c3916a3238cb Mon Sep 17 00:00:00 2001 From: Wen Congyang<wency@cn.fujitsu.com> Date: Sat, 2 Jul 2011 06:41:18 +0800 Subject: [PATCH] initialize pointer to NULL
def and cmd is not initialized to NULL, but we try to freed it if we meet some error. It's very dangerous.
Well, really it's not necessary to initialize def to NULL, because VIR_ALLOC(def) is always called before any point in the code that might goto the error label. So by the time you could get any error, def is already either a valid pointer, or NULL. cmd definitely *does* need to be initialized to NULL, though, because it doesn't get VIR_ALLOCed until after the check for failure of VIR_ALLOC(def) (and resulting goto no_memory). ACK on initializing cmd. Whether or not to initialize def is a matter of style. I prefer not, but others may prefer to do it just in case code is added in the future that causes a jump that bypasses VIR_ALLOC(def).
--- src/qemu/qemu_command.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 90a6653..6c78161 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -5818,7 +5818,7 @@ virDomainDefPtr qemuParseCommandLine(virCapsPtr caps, const char **progenv, const char **progargv) { - virDomainDefPtr def; + virDomainDefPtr def = NULL; int i; int nographics = 0; int fullscreen = 0; @@ -5827,7 +5827,7 @@ virDomainDefPtr qemuParseCommandLine(virCapsPtr caps, const char **nics = NULL; int video = VIR_DOMAIN_VIDEO_TYPE_CIRRUS; int nvirtiodisk = 0; - qemuDomainCmdlineDefPtr cmd; + qemuDomainCmdlineDefPtr cmd = NULL;
if (!progargv[0]) { qemuReportError(VIR_ERR_INTERNAL_ERROR,
On Sat, Jul 02, 2011 at 10:27:38PM -0400, Laine Stump wrote:
On 07/02/2011 08:55 AM, Wen Congyang wrote:
From 577ac7e8594cbcccb59653786e80c3916a3238cb Mon Sep 17 00:00:00 2001 From: Wen Congyang<wency@cn.fujitsu.com> Date: Sat, 2 Jul 2011 06:41:18 +0800 Subject: [PATCH] initialize pointer to NULL
def and cmd is not initialized to NULL, but we try to freed it if we meet some error. It's very dangerous.
Well, really it's not necessary to initialize def to NULL, because VIR_ALLOC(def) is always called before any point in the code that might goto the error label. So by the time you could get any error, def is already either a valid pointer, or NULL.
cmd definitely *does* need to be initialized to NULL, though, because it doesn't get VIR_ALLOCed until after the check for failure of VIR_ALLOC(def) (and resulting goto no_memory).
ACK on initializing cmd. Whether or not to initialize def is a matter of style. I prefer not, but others may prefer to do it just in case code is added in the future that causes a jump that bypasses VIR_ALLOC(def).
Okay, ACK, I just commited the initialization for cmd, thanks ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
participants (3)
-
Daniel Veillard -
Laine Stump -
Wen Congyang