Re: Data member with same name as enclosing class

Re: Data member with same name as enclosing class

[Klaus Kaempf]

>>> > extern "C" {
>>> > struct ip_opts
>>> >   {
>>> >     struct in_addr ip_dst;
>>> >     char ip_opts[40];
>>> >   }
>>> > ...
>>> > } /* extern "C"  */
>>> > 
>>> [...]


>It should be noted that code inside `extern "C"' *must* be valid
>C++. `extern "C"' does not mean "hey, this is C not C++". `extern "C"'
>has to do with linkage. Period. 


Allright, then the Linux include file is wrong !
Who's to blame ?!

Re: Data member with same name as enclosing class

[Andi Kleen]

In article < 001f01be4569$d35813c0$1204a8c0@klausk.ditech.de >,
Klaus.Kaempf@DITECH.DE (Klaus Kaempf) writes:
>>>> > extern "C" {
>>>> > struct ip_opts
>>>> >   {
>>>> >     struct in_addr ip_dst;
>>>> >     char ip_opts[40];
>>>> >   }
>>>> > ...
>>>> > } /* extern "C"  */
>>>> > 
>>>> [...]


>> It should be noted that code inside `extern "C"' *must* be valid
>> C++. `extern "C"' does not mean "hey, this is C not C++". `extern "C"'
>> has to do with linkage. Period. 


> Allright, then the Linux include file is wrong !
> Who's to blame ?!

Noone. Noone ever claimed that Linux include files are valid C++. 

  
-Andi

Re: Data member with same name as enclosing class

[Jason Merrill]

>>>>> Andi Kleen <ak@muc.de> writes:

 > In article < 001f01be4569$d35813c0$1204a8c0@klausk.ditech.de >,
 > Klaus.Kaempf@DITECH.DE (Klaus Kaempf) writes:
 >>>>> > extern "C" {
 >>>>> > struct ip_opts
 >>>>> >   {
 >>>>> >     struct in_addr ip_dst;
 >>>>> >     char ip_opts[40];
 >>>>> >   }
 >>>>> > ...
 >>>>> > } /* extern "C"  */
 >>>>> > 
 >>>>> [...]

 >>> It should be noted that code inside `extern "C"' *must* be valid
 >>> C++. `extern "C"' does not mean "hey, this is C not C++". `extern "C"'
 >>> has to do with linkage. Period. 

 >> Allright, then the Linux include file is wrong !
 >> Who's to blame ?!

Nobody.  The include file was written before C++ became popular, and long
before this construction was made invalid (at the May 1996 meeting).
netinet/in.h dates back at least to 1989, and probably well before.
I brought this issue up to the C++ committee a few weeks ago, and nobody
had a coherent suggestion as to what to do; I decided to just accept this
code within extern "C".

Jason

Re: Data member with same name as enclosing class

[Martin v. Loewis]

> Allright, then the Linux include file is wrong !
> Who's to blame ?!

I think glibc. If this is really mandated by some standard, it should
be #ifdefed with the relevant feature.

Regards,
Martin

Re: Data member with same name as enclosing class

[Martin v. Loewis]

> Allright, then the Linux include file is wrong !
> Who's to blame ?!

I think glibc. If this is really mandated by some standard, it should
be #ifdefed with the relevant feature.

Regards,
Martin

Re: Data member with same name as enclosing class

[Andi Kleen]

In article < 001f01be4569$d35813c0$1204a8c0@klausk.ditech.de >,
Klaus.Kaempf@DITECH.DE (Klaus Kaempf) writes:
>>>> > extern "C" {
>>>> > struct ip_opts
>>>> >   {
>>>> >     struct in_addr ip_dst;
>>>> >     char ip_opts[40];
>>>> >   }
>>>> > ...
>>>> > } /* extern "C"  */
>>>> > 
>>>> [...]


>> It should be noted that code inside `extern "C"' *must* be valid
>> C++. `extern "C"' does not mean "hey, this is C not C++". `extern "C"'
>> has to do with linkage. Period. 


> Allright, then the Linux include file is wrong !
> Who's to blame ?!

Noone. Noone ever claimed that Linux include files are valid C++. 

  
-Andi

Re: Data member with same name as enclosing class

[Klaus Kaempf]

>>> > extern "C" {
>>> > struct ip_opts
>>> >   {
>>> >     struct in_addr ip_dst;
>>> >     char ip_opts[40];
>>> >   }
>>> > ...
>>> > } /* extern "C"  */
>>> > 
>>> [...]


>It should be noted that code inside `extern "C"' *must* be valid
>C++. `extern "C"' does not mean "hey, this is C not C++". `extern "C"'
>has to do with linkage. Period. 


Allright, then the Linux include file is wrong !
Who's to blame ?!

Re: Data member with same name as enclosing class

[Jason Merrill]

>>>>> Andi Kleen <ak@muc.de> writes:

 > In article < 001f01be4569$d35813c0$1204a8c0@klausk.ditech.de >,
 > Klaus.Kaempf@DITECH.DE (Klaus Kaempf) writes:
 >>>>> > extern "C" {
 >>>>> > struct ip_opts
 >>>>> >   {
 >>>>> >     struct in_addr ip_dst;
 >>>>> >     char ip_opts[40];
 >>>>> >   }
 >>>>> > ...
 >>>>> > } /* extern "C"  */
 >>>>> > 
 >>>>> [...]

 >>> It should be noted that code inside `extern "C"' *must* be valid
 >>> C++. `extern "C"' does not mean "hey, this is C not C++". `extern "C"'
 >>> has to do with linkage. Period. 

 >> Allright, then the Linux include file is wrong !
 >> Who's to blame ?!

Nobody.  The include file was written before C++ became popular, and long
before this construction was made invalid (at the May 1996 meeting).
netinet/in.h dates back at least to 1989, and probably well before.
I brought this issue up to the C++ committee a few weeks ago, and nobody
had a coherent suggestion as to what to do; I decided to just accept this
code within extern "C".

Jason

Re: Data member with same name as enclosing class

[Matthias Urlichs]

Hi,

Martin v. Loewis:
> > extern "C" {
> > struct ip_opts
> >   {
> >     struct in_addr ip_dst;
> >     char ip_opts[40];
> >   }
> > ...
> > } /* extern "C"  */
> > 
> [...]
> > Question is: Should this error message be suppressed for 'extern
> > "C"' structs or should the include file be changed ?
> 
> This is invalid C++, so it should be rejected.
> 
Hmm. It would be cool (even though The Standard probably prohibits it...)
if g++ would automagically turn off all C++ features inside 'extern "C"',
not just the name mangling...

-- 
Matthias Urlichs  |  noris network GmbH   |   smurf@noris.de  |  ICQ: 20193661
The quote was selected randomly. Really.    |      http://www.noris.de/~smurf/
-- 
Carson's Observation on Footwear:
       If the shoe fits, buy the other one too.

Data member with same name as enclosing class

[Klaus Kaempf]

When compiling Mozilla with egcs-2.93.02 (cvs snapshot from yesterday) I
stumbled across the
following error on RedHat linux 5.1

A c++ file includes "/usr/include/netinet/in.h" with has

extern "C" {
...
struct ip_opts
  {
    struct in_addr ip_dst;
    char ip_opts[40];
  }
...
} /* extern "C"  */


The c++ compiler stops with "Ansi C++ forbids data member with same name as
enclosing class".

Question is: Should this error message be suppressed for 'extern "C"'
structs or should the
include file be changed ?

Re: Data member with same name as enclosing class

[Jason Merrill]

>>>>> Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

 >> Pedantically, yes.  The problem is that this occurs in a header that has
 >> been around for a long time, so we have to deal with it somehow.

 > Is this really the case? I tried finding that structure on Solaris,
 > and couldn't. Also, the documentation indicates that you are supposed
 > to fill the bytes of the structure yourself, rather than relying on
 > a structure being defined.

The same construct occurs in the AIX header, which appears to come from
BSD.

 > Even if this really turns out to be mandated by some obscure API, I
 > still think that pedantically, we'd have to reject it. In turn, you
 > cannot compile an application that uses <netinet/something> with
 > -pedantic. What a pity.

In theory.  I'm not too worried about diverging on this particular point.

Jason

Re: Data member with same name as enclosing class

[Gabriel Dos Reis]

>>>>> Matthias Urlichs <smurf@noris.de> wrote:

> Hi,
> Martin v. Loewis:
>> > extern "C" {
>> > struct ip_opts
>> >   {
>> >     struct in_addr ip_dst;
>> >     char ip_opts[40];
>> >   }
>> > ...
>> > } /* extern "C"  */
>> > 
>> [...]
>> > Question is: Should this error message be suppressed for 'extern
>> > "C"' structs or should the include file be changed ?
>> 
>> This is invalid C++, so it should be rejected.
>> 
> Hmm. It would be cool (even though The Standard probably prohibits it...)
> if g++ would automagically turn off all C++ features inside 'extern "C"',
> not just the name mangling...

It should be noted that code inside `extern "C"' *must* be valid
C++. `extern "C"' does not mean "hey, this is C not C++". `extern "C"'
has to do with linkage. Period. 

-- Gaby

Re: Data member with same name as enclosing class

[Martin v. Loewis]

> Pedantically, yes.  The problem is that this occurs in a header that has
> been around for a long time, so we have to deal with it somehow.

Is this really the case? I tried finding that structure on Solaris,
and couldn't. Also, the documentation indicates that you are supposed
to fill the bytes of the structure yourself, rather than relying on
a structure being defined.

Even if this really turns out to be mandated by some obscure API, I
still think that pedantically, we'd have to reject it. In turn, you
cannot compile an application that uses <netinet/something> with
-pedantic. What a pity.

Martin

Re: Data member with same name as enclosing class

[Martin v. Loewis]

> extern "C" {
> struct ip_opts
>   {
>     struct in_addr ip_dst;
>     char ip_opts[40];
>   }
> ...
> } /* extern "C"  */
> 
[...]
> Question is: Should this error message be suppressed for 'extern
> "C"' structs or should the include file be changed ?

This is invalid C++, so it should be rejected.

Regards,
Martin

Re: Data member with same name as enclosing class

[Jason Merrill]

>>>>> Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

 >> extern "C" {
 >> struct ip_opts
 >>   {
 >>     struct in_addr ip_dst;
 >>     char ip_opts[40];
 >>   }
 >> ...
 >> } /* extern "C"  */
 >> 
 > [...]
 >> Question is: Should this error message be suppressed for 'extern
 >> "C"' structs or should the include file be changed ?

 > This is invalid C++, so it should be rejected.

Pedantically, yes.  The problem is that this occurs in a header that has
been around for a long time, so we have to deal with it somehow.

Jason

Re: Data member with same name as enclosing class

[Jason Merrill]

>>>>> Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

 >> Pedantically, yes.  The problem is that this occurs in a header that has
 >> been around for a long time, so we have to deal with it somehow.

 > Is this really the case? I tried finding that structure on Solaris,
 > and couldn't. Also, the documentation indicates that you are supposed
 > to fill the bytes of the structure yourself, rather than relying on
 > a structure being defined.

The same construct occurs in the AIX header, which appears to come from
BSD.

 > Even if this really turns out to be mandated by some obscure API, I
 > still think that pedantically, we'd have to reject it. In turn, you
 > cannot compile an application that uses <netinet/something> with
 > -pedantic. What a pity.

In theory.  I'm not too worried about diverging on this particular point.

Jason

Re: Data member with same name as enclosing class

[Martin v. Loewis]

> Pedantically, yes.  The problem is that this occurs in a header that has
> been around for a long time, so we have to deal with it somehow.

Is this really the case? I tried finding that structure on Solaris,
and couldn't. Also, the documentation indicates that you are supposed
to fill the bytes of the structure yourself, rather than relying on
a structure being defined.

Even if this really turns out to be mandated by some obscure API, I
still think that pedantically, we'd have to reject it. In turn, you
cannot compile an application that uses <netinet/something> with
-pedantic. What a pity.

Martin

Re: Data member with same name as enclosing class

[Gabriel Dos Reis]

>>>>> Matthias Urlichs <smurf@noris.de> wrote:

> Hi,
> Martin v. Loewis:
>> > extern "C" {
>> > struct ip_opts
>> >   {
>> >     struct in_addr ip_dst;
>> >     char ip_opts[40];
>> >   }
>> > ...
>> > } /* extern "C"  */
>> > 
>> [...]
>> > Question is: Should this error message be suppressed for 'extern
>> > "C"' structs or should the include file be changed ?
>> 
>> This is invalid C++, so it should be rejected.
>> 
> Hmm. It would be cool (even though The Standard probably prohibits it...)
> if g++ would automagically turn off all C++ features inside 'extern "C"',
> not just the name mangling...

It should be noted that code inside `extern "C"' *must* be valid
C++. `extern "C"' does not mean "hey, this is C not C++". `extern "C"'
has to do with linkage. Period. 

-- Gaby

Re: Data member with same name as enclosing class

[Matthias Urlichs]

Hi,

Martin v. Loewis:
> > extern "C" {
> > struct ip_opts
> >   {
> >     struct in_addr ip_dst;
> >     char ip_opts[40];
> >   }
> > ...
> > } /* extern "C"  */
> > 
> [...]
> > Question is: Should this error message be suppressed for 'extern
> > "C"' structs or should the include file be changed ?
> 
> This is invalid C++, so it should be rejected.
> 
Hmm. It would be cool (even though The Standard probably prohibits it...)
if g++ would automagically turn off all C++ features inside 'extern "C"',
not just the name mangling...

-- 
Matthias Urlichs  |  noris network GmbH   |   smurf@noris.de  |  ICQ: 20193661
The quote was selected randomly. Really.    |      http://www.noris.de/~smurf/
-- 
Carson's Observation on Footwear:
       If the shoe fits, buy the other one too.

Re: Data member with same name as enclosing class

[Jason Merrill]

>>>>> Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

 >> extern "C" {
 >> struct ip_opts
 >>   {
 >>     struct in_addr ip_dst;
 >>     char ip_opts[40];
 >>   }
 >> ...
 >> } /* extern "C"  */
 >> 
 > [...]
 >> Question is: Should this error message be suppressed for 'extern
 >> "C"' structs or should the include file be changed ?

 > This is invalid C++, so it should be rejected.

Pedantically, yes.  The problem is that this occurs in a header that has
been around for a long time, so we have to deal with it somehow.

Jason