7:55 a.m.
From 577ac7e8594cbcccb59653786e80c3916a3238cb Mon Sep 17 00:00:00 2001
From: Wen Congyang <wency(a)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
9:27 p.m.
On 07/02/2011 08:55 AM, Wen Congyang wrote:
> From 577ac7e8594cbcccb59653786e80c3916a3238cb Mon Sep 17
00:00:00 2001
From: Wen Congyang<wency(a)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,
1:02 a.m.
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(a)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(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
4890
days inactive
4892
days old
2 comments
3 participants
participants (3)
-
Daniel Veillard -
Laine Stump -
Wen Congyang