From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1L6q1w-0000lk-Ix
	for qemu-devel@nongnu.org; Sun, 30 Nov 2008 12:24:24 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1L6q1v-0000l1-1z
	for qemu-devel@nongnu.org; Sun, 30 Nov 2008 12:24:24 -0500
Received: from [199.232.76.173] (port=49199 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1L6q1u-0000kt-Po
	for qemu-devel@nongnu.org; Sun, 30 Nov 2008 12:24:22 -0500
Received: from bsdimp.com ([199.45.160.85]:49888 helo=harmony.bsdimp.com)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <imp@bsdimp.com>) id 1L6q1u-0000b5-36
	for qemu-devel@nongnu.org; Sun, 30 Nov 2008 12:24:22 -0500
Date: Sun, 30 Nov 2008 10:21:59 -0700 (MST)
Message-Id: <20081130.102159.1628339025.imp@bsdimp.com>
Subject: Re: [Qemu-devel] Re: [PATCH 2/2] Add __noreturn function attribute
From: "M. Warner Losh" <imp@bsdimp.com>
In-Reply-To: <49328C7F.1050705@mail.berlios.de>
References: <761ea48b0811300400l6edcc1f6g63261dd8b4629574@mail.gmail.com>
	<49328941.9050908@web.de> <49328C7F.1050705@mail.berlios.de>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org, weil@mail.berlios.de

In message: <49328C7F.1050705@mail.berlios.de>
            Stefan Weil <weil@mail.berlios.de> writes:
: Jan Kiszka schrieb:
: > Laurent Desnogues wrote:
: >> On Sun, Nov 30, 2008 at 12:51 PM, Stefan Weil <berlios@weilnetz.de>
: >> wrote:
: >>> Why do we need a new macro instead of just using __attribute__
: >>> ((__noreturn__))?
: >> Don't we need it to prevent gcc-ism from being all over the code?
: >
: > Yep, and that's also why we need wrapping. You can easily define it away
: > if your compiler doesn't support it. We just need to add the required
: > conditions.
: >
: >> Though I wonder how much tcg converted code still depends on
: >> being compiled by gcc.
: >
: > I guess once the hard dependencies are removed, fixing things like the
: > existing __attributes__ etc. will just be mechanical work.
: >
: > Jan
: >
: 
: 
: For compilers which don't support __attributes__, a simple
: 
: #define __attributes__(dummy) /* dummy */
: 
: or an equivalent command line option would eliminate all gcc-isms.
: I don't think we need wrapping, at least not now.

This doesn't work so well when 'dummy' is __packed__.

The BSD projects have had similar macros for a long long time, and
they work out well in practice.

Warner