From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47090) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XHsOp-00081p-UE for qemu-devel@nongnu.org; Thu, 14 Aug 2014 06:36:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XHsOl-0001fz-3r for qemu-devel@nongnu.org; Thu, 14 Aug 2014 06:36:51 -0400 Date: Thu, 14 Aug 2014 12:36:22 +0200 From: "Michael S. Tsirkin" Message-ID: <20140814103622.GI31346@redhat.com> References: <1408001361-13580-1-git-send-email-zhang.zhanghailiang@huawei.com> <1408001361-13580-11-git-send-email-zhang.zhanghailiang@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1408001361-13580-11-git-send-email-zhang.zhanghailiang@huawei.com> Subject: Re: [Qemu-devel] [PATCH v6 10/10] block/vvfat: fix setbuf stream parameter may be NULL List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: zhanghailiang Cc: kwolf@redhat.com, lkurusa@redhat.com, qemu-trivial@nongnu.org, jan.kiszka@siemens.com, riku.voipio@iki.fi, mjt@tls.msk.ru, qemu-devel@nongnu.org, lcapitulino@redhat.com, stefanha@redhat.com, Li Liu , luonengjun@huawei.com, pbonzini@redhat.com, peter.huangpeng@huawei.com, alex.bennee@linaro.org, rth@twiddle.net On Thu, Aug 14, 2014 at 03:29:21PM +0800, zhanghailiang wrote: > From: Li Liu > > fopen() may return NULL which will cause setbuf() segmentfault > > Signed-off-by: zhanghailiang > Signed-off-by: Li Liu > --- > block/vvfat.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/block/vvfat.c b/block/vvfat.c > index 70176b1..6889ea9 100644 > --- a/block/vvfat.c > +++ b/block/vvfat.c > @@ -1084,7 +1084,10 @@ static int vvfat_open(BlockDriverState *bs, QDict *options, int flags, > > DLOG(if (stderr == NULL) { > stderr = fopen("vvfat.log", "a"); > - setbuf(stderr, NULL); > + > + if (stderr) { > + setbuf(stderr, NULL); > + } > }) > > opts = qemu_opts_create(&runtime_opts, NULL, 0, &error_abort); I would say assert on failure here. If one is trying to debug, seeing no output will just confuse matters more. > -- > 1.7.12.4 >