From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28622 invoked by alias); 31 Jul 2003 11:50:37 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 28573 invoked from network); 31 Jul 2003 11:50:37 -0000 Received: from unknown (HELO nile.gnat.com) (205.232.38.5) by sources.redhat.com with SMTP; 31 Jul 2003 11:50:37 -0000 Received: by nile.gnat.com (Postfix, from userid 338) id 06662F2DDA; Thu, 31 Jul 2003 07:50:37 -0400 (EDT) To: dewar@gnat.com, gdr@integrable-solutions.net Subject: Re: definition of "implicit" inline? Cc: gcc@gcc.gnu.org, martin@MPA-Garching.MPG.DE Message-Id: <20030731115037.06662F2DDA@nile.gnat.com> Date: Thu, 31 Jul 2003 13:53:00 -0000 From: dewar@gnat.com (Robert Dewar) X-SW-Source: 2003-07/txt/msg02304.txt.bz2 So, the quotes from the standard make it clear that the explicit inline keyword is significant. I have no idea how the standard could be read otherwise. > The inline specifier indicates to the implementation that inline > substitution of the function body at the point of call is to be > preferred to the usual function call mechanism. Of course that's pretty meaningless given that all semantics is "as if". Whenever the standard appears to demand a particular code sequence, appearences are deceptive! > There is no consensus, either, that the current logic is good. > I'm not shouting louder. I'm just trying to get people to consider > the *language* _under discussion_ and to prevent them from transmuting > the intent of the keyword. But your quotes from the standard make it clear that no one is transmuting anything here.