From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=FROM_EXCESS_BASE64, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 80E1EC7618B for ; Thu, 25 Jul 2019 09:24:23 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2FAFA218EA for ; Thu, 25 Jul 2019 09:24:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2FAFA218EA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:57568 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hqZz4-000226-Ee for qemu-devel@archiver.kernel.org; Thu, 25 Jul 2019 05:24:22 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37260) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hqZyu-0001cV-G8 for qemu-devel@nongnu.org; Thu, 25 Jul 2019 05:24:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hqZyt-0007Re-Df for qemu-devel@nongnu.org; Thu, 25 Jul 2019 05:24:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40494) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hqZyt-0007Qr-7O for qemu-devel@nongnu.org; Thu, 25 Jul 2019 05:24:11 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 095B6308427C; Thu, 25 Jul 2019 09:24:10 +0000 (UTC) Received: from redhat.com (ovpn-112-56.ams2.redhat.com [10.36.112.56]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 09B8A5DD97; Thu, 25 Jul 2019 09:24:08 +0000 (UTC) Date: Thu, 25 Jul 2019 10:24:05 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Peter Maydell Message-ID: <20190725092405.GB6930@redhat.com> References: <20190723154856.17348-1-berrange@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.0 (2019-05-25) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.40]); Thu, 25 Jul 2019 09:24:10 +0000 (UTC) Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: Re: [Qemu-devel] [PATCH for 4.2 0/3] require newer glib2 to enable autofree'ing of stack variables exiting scope X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Cc: QEMU Developers Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Thu, Jul 25, 2019 at 10:13:11AM +0100, Peter Maydell wrote: > On Tue, 23 Jul 2019 at 16:49, Daniel P. Berrang=C3=A9 wrote: > > > > Both GCC and CLang support a C extension attribute((cleanup)) which > > allows you to define a function that is invoked when a stack variable > > exits scope. This typically used to free the memory allocated to it, > > though you're not restricted to this. For example it could be used to > > unlock a mutex. >=20 > Does Coverity handle this? Can it be made to wire up this kind > of deallocation into checks of use-after-free/memory leaks/etc? I believe so, in so much as it has not complained about leaks in libvirt where we've removed the free() calls in favour of the attribute(cleanup) annotations. I'm presuming this is because the free() calls do still exist - they're simply automatically added in all paths that exist a code scope. You can still see the free() calls in GDB stack traces for example. Regards, Daniel --=20 |: https://berrange.com -o- https://www.flickr.com/photos/dberran= ge :| |: https://libvirt.org -o- https://fstop138.berrange.c= om :| |: https://entangle-photo.org -o- https://www.instagram.com/dberran= ge :|