gcc 2.95.x interesting c++ parser error (bug).

gcc 2.95.x interesting c++ parser error (bug).

[Karel Gardas]

Hi,

It looks like that c++ parser in gcc 2.95.x doesn't like some param names
like '__op' and '__rs'. These names confuse parser and then it produce
error messages regarding ''declaration of operator '<something>' as
non-function''

Here is small example:


class Foo
{
public:
    void
    method(char* __op_name); // OK

    //  gcc2.95-wrong-param-name-bug.cc:9: declaration of `operator ' as non-function
    //  gcc2.95-wrong-param-name-bug.cc:9: confused by earlier errors, bailing out
    void
    method2(int __op); // error

    void
    method3(long __reply_status); // OK

    //  gcc2.95-wrong-param-name-bug.cc:17: declaration of `operator >>' as non-function
    //  gcc2.95-wrong-param-name-bug.cc:17: confused by earlier errors, bailing out
    void
    method4(short __rs); // error
};

int
main()
{
    return 0;
}


I know that the main focus of development is concentrated on upcoming gcc
3.1 release, but I think that someone might be interested (for example
Debian or FreeBSD 4.x gcc maintainers) and so I've posted this email,
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).

Cheers,

Karel

PS: Tested on Debian GNU/Linux 3.0 and FreeBSD 4.5.

bash-2.05$ gcc -v
Using builtin specs.
gcc version 2.95.3 20010315 (release) [FreeBSD]
bash-2.05$

thinkpad:~/cvs/mt-micosec-csiv2/mico$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
thinkpad:~/cvs/mt-micosec-csiv2/mico$
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

Re: gcc 2.95.x interesting c++ parser error (bug).

[Florian Weimer]

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).

Re: gcc 2.95.x interesting c++ parser error (bug).

[Karel Gardas]

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.

Cheers,

Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

Re: gcc 2.95.x interesting c++ parser error (bug).

[Florian Weimer]

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. ;-)

Re: gcc 2.95.x interesting c++ parser error (bug).

[Jason Merrill]

>>>>> "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

Re: gcc 2.95.x interesting c++ parser error (bug).

[Karel Gardas]

On Thu, 25 Apr 2002, Jason Merrill wrote:

> >>>>> "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.

Yes, I see, but I like this coding style. :-( Is there any prefered GNU
coding style for c++ projects?

Thanks,

Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

Re: gcc 2.95.x interesting c++ parser error (bug).

[Phil Edwards]

On Thu, Apr 25, 2002 at 04:36:12PM +0200, Karel Gardas wrote:
> On Thu, 25 Apr 2002, Jason Merrill wrote:
> > 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.
> 
> Yes, I see, but I like this coding style. :-( Is there any prefered GNU
> coding style for c++ projects?

Not as such.  The published GNU coding standards (the command "info
standards" should display them) were written by C programmers, and
even today adivse against the use of any language other than C for most
programming projects.  So they're not much help.  For libstdc++ we took
the indentation and commenting rules from there, and added the uglification
rules because Koenig lookup is a feature not found in C.

No C++ guidelines have been agreed on and published because 1) it's such
a religious topic, and 2) it doesn't really matter.  I like the technique
found in some of the better C++ books, where member data variables have
a trailing underscore, but that's just me.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams