From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-50662-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 30926 invoked by alias); 25 Apr 2002 10:16:02 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 30918 invoked from network); 25 Apr 2002 10:15:54 -0000
Received: from unknown (HELO executor.cambridge.redhat.com) (195.224.55.237)
  by sources.redhat.com with SMTP; 25 Apr 2002 10:15:54 -0000
Received: from prospero.cambridge.redhat.com (dell-paw-2.cambridge.redhat.com [195.224.55.226])
	by executor.cambridge.redhat.com (Postfix) with ESMTP
	id 24509ABAF8; Thu, 25 Apr 2002 11:15:50 +0100 (BST)
Received: by prospero.cambridge.redhat.com (Postfix, from userid 4046)
	id B6FE4F7B7A; Thu, 25 Apr 2002 11:15:47 +0100 (BST)
To: Florian Weimer <fw@deneb.enyo.de>
Cc: Karel Gardas <kgardas@objectsecurity.com>, gcc@gcc.gnu.org
Subject: Re: gcc 2.95.x interesting c++ parser error (bug).
References: <Pine.LNX.4.43.0204212027100.476-100000@thinkpad.objectsecurity.cz>
	<87wuv07nwd.fsf@deneb.enyo.de>
From: Jason Merrill <jason@redhat.com>
In-Reply-To: <87wuv07nwd.fsf@deneb.enyo.de> (Florian Weimer's message of
 "Sun, 21 Apr 2002 23:16:50 +0200")
Date: Thu, 25 Apr 2002 03:31:00 -0000
Message-ID: <wvllmbct770.fsf@prospero.cambridge.redhat.com>
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i686-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-SW-Source: 2002-04/txt/msg01314.txt.bz2

>>>>> "Florian" == Florian Weimer <fw@deneb.enyo.de> writes:

> Karel Gardas <kgardas@objectsecurity.com> writes:
>> On Sun, 21 Apr 2002, Florian Weimer wrote:
>> 
>>> Karel Gardas <kgardas@objectsecurity.com> writes:
>>> 
>>> > because it takes me some time to find exact place in my sources which
>>> > cause this bug (these sources are of course perfectly OK with gcc 3.1).
>>> 
>>> The sources aren't perfectly okay.  You must not use identifiers with
>>> two leading underscores (see section 17.4.3.1.2 in ISO/IEC 14882).
>> 
>> Interesting, but it's described in GNU C++ coding style (for libstdc++) to
>> use double underscores for local (temporary) variable and method/function
>> parameters.

> Well, 17.4.3.1.2 reserves these identifiers to implementors, so you
> can expect implementors to use them. ;-)

Exactly.  They are used in libstdc++ specifically because you (as a user)
aren't allowed to use them, so they can't conflict with any macros you
might define.

Jason