Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763071AbXEYTk0 (ORCPT ); Fri, 25 May 2007 15:40:26 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753313AbXEYTkT (ORCPT ); Fri, 25 May 2007 15:40:19 -0400 Received: from terminus.zytor.com ([192.83.249.54]:42823 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753088AbXEYTkR (ORCPT ); Fri, 25 May 2007 15:40:17 -0400 Message-ID: <46573B23.1090700@zytor.com> Date: Fri, 25 May 2007 12:38:11 -0700 From: "H. Peter Anvin" User-Agent: Thunderbird 2.0.0.0 (X11/20070419) MIME-Version: 1.0 To: "Robert P. J. Day" CC: Linux Kernel Mailing List , Ralf Baechle Subject: Re: [PATCH] MIPS: Transform old-style macros to newer "__noreturn" standard. References: <46572DAF.1000108@zytor.com> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 779 Lines: 33 Robert P. J. Day wrote: > > > f() __attribute__((noreturn)) ; > > you get: > > warning: data definition has no type or storage class > > but gcc doesn't complain if you declare it thusly: > > __attribute__((noreturn)) f() ; > > that strikes me as a flaw in gcc, no? > Doesn't matter. gcc accepts "void __attribute__((noreturn)) f();", and thus, one can define: #define __noreturn void __attribute__((noreturn)) ... and declare functions as: __noreturn f(); ... which is the syntactially sane way of doing it. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/