Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751923AbXEXRMn (ORCPT ); Thu, 24 May 2007 13:12:43 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750754AbXEXRMg (ORCPT ); Thu, 24 May 2007 13:12:36 -0400 Received: from an-out-0708.google.com ([209.85.132.245]:51514 "EHLO an-out-0708.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750741AbXEXRMf (ORCPT ); Thu, 24 May 2007 13:12:35 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MLmV3wSzWV3TWByCYJJt5Axx3c1Pf/0Cj7wstHnwx1si1oUCfiPmlZyu9S7o4jiJBsG75+SqWjCLTivz1hiOxKyLb+1+NmMI8YCAo7QTbTowhqMUS1jtNendnrBzx/rrJ03f1sq6MO2WaUbyKXJN5rDn7yM6Kk+QIudxkVPt1Ew= Message-ID: Date: Thu, 24 May 2007 22:42:27 +0530 From: "Satyam Sharma" To: "Krzysztof Halasa" Subject: Re: any value to "NORET_TYPE" macro? Cc: "Robert P. J. Day" , "Adrian Bunk" , "Linux Kernel Mailing List" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070522161951.GC2098@stusta.de> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2253 Lines: 48 On 5/24/07, Krzysztof Halasa wrote: > "Satyam Sharma" writes: > > > Actually there's another thing :-) The __attribute__((xxx)) must go with the > > function _declarations_ (and not the implementations/definitions). I noticed > > after my previous mail that most of the double annotations are actually in > > the case of the _declarations_ of these non-returning functions, whereas > > most of the single-occurrences of NORET_TYPE were in the function > > definitions, which means your patch that simply got rid of NORET_TYPE > > actually ended up doing exactly the right thing that we wanted :-) > > Only half of it. Half of right thing is (here) a bad thing. > > NORET_TYPE does not do any harm. > Removing it removes pointers to attrib((noreturn)) candidates. > Simple. NORET_TYPE didn't do any harm because it expanded to /**/. But yes, removing it does remove the annotations / markers for ATTRIB_NORET candidates, as I first mentioned to Rday. But later on going through the code, I noticed that: 1. Most of the combined occurrences of NORET_TYPE along with ATTRIB_NORET were in function _declarations_. So here, what we want is to simply remove the NORET_TYPE, and *not* replace it with ATTRIB_NORET, because it's already there! 2. Most of the single-occurrences (NORET_TYPE alone, without any ATTRIB_NORET) were in function _implementations_. So here, what we want is to simply remove the NORET_TYPE, and *not* introduce any ATTRIB_NORET, because it's not required! In such a situation, merging a patch that simply gets rid of NORET_TYPE (i.e. s/NORET_TYPE//) actually ends up doing the right thing! ... *however* ... as I mentioned next, unfortunately the above 2 points did not hold for _all_ occurrences of NORET_TYPE. There were some exceptions (which also I mentioned) where we want to do somethings slightly more complicated, so I put the ball in Rday's court -- he had originally expressed a wish to avoid doing complicated things in this patch. - 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/