* Re: Data member with same name as enclosing class
[not found] ` <199901202031.VAA00823.cygnus.egcs@mira.isdn.cs.tu-berlin.de>
@ 1999-01-21 1:05 ` Jason Merrill
1999-01-21 15:08 ` Martin v. Loewis
1999-01-31 23:58 ` Jason Merrill
0 siblings, 2 replies; 20+ messages in thread
From: Jason Merrill @ 1999-01-21 1:05 UTC (permalink / raw)
To: Martin v. Loewis, egcs
>>>>> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Data member with same name as enclosing class
1999-01-31 23:58 ` Martin v. Loewis
@ 1999-01-21 8:37 ` Matthias Urlichs
1999-01-21 9:07 ` Gabriel Dos Reis
1999-01-31 23:58 ` Matthias Urlichs
0 siblings, 2 replies; 20+ messages in thread
From: Matthias Urlichs @ 1999-01-21 8:37 UTC (permalink / raw)
To: Martin v. Loewis; +Cc: Klaus.Kaempf, egcs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Data member with same name as enclosing class
1999-01-21 8:37 ` Matthias Urlichs
@ 1999-01-21 9:07 ` Gabriel Dos Reis
1999-01-31 23:58 ` Gabriel Dos Reis
1999-01-31 23:58 ` Matthias Urlichs
1 sibling, 1 reply; 20+ messages in thread
From: Gabriel Dos Reis @ 1999-01-21 9:07 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: Martin v. Loewis, Klaus.Kaempf, egcs
>>>>> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Data member with same name as enclosing class
1999-01-21 1:05 ` Jason Merrill
@ 1999-01-21 15:08 ` Martin v. Loewis
1999-01-21 18:29 ` Jason Merrill
1999-01-31 23:58 ` Martin v. Loewis
1999-01-31 23:58 ` Jason Merrill
1 sibling, 2 replies; 20+ messages in thread
From: Martin v. Loewis @ 1999-01-21 15:08 UTC (permalink / raw)
To: jason; +Cc: egcs
> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Data member with same name as enclosing class
1999-01-21 15:08 ` Martin v. Loewis
@ 1999-01-21 18:29 ` Jason Merrill
1999-01-31 23:58 ` Jason Merrill
1999-01-31 23:58 ` Martin v. Loewis
1 sibling, 1 reply; 20+ messages in thread
From: Jason Merrill @ 1999-01-21 18:29 UTC (permalink / raw)
To: Martin v. Loewis; +Cc: egcs
>>>>> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Data member with same name as enclosing class
1999-01-21 8:37 ` Matthias Urlichs
1999-01-21 9:07 ` Gabriel Dos Reis
@ 1999-01-31 23:58 ` Matthias Urlichs
1 sibling, 0 replies; 20+ messages in thread
From: Matthias Urlichs @ 1999-01-31 23:58 UTC (permalink / raw)
To: Martin v. Loewis; +Cc: Klaus.Kaempf, egcs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Data member with same name as enclosing class
@ 1999-01-31 23:58 Klaus Kaempf
[not found] ` <199901202031.VAA00823.cygnus.egcs@mira.isdn.cs.tu-berlin.de>
1999-01-31 23:58 ` Martin v. Loewis
0 siblings, 2 replies; 20+ messages in thread
From: Klaus Kaempf @ 1999-01-31 23:58 UTC (permalink / raw)
To: egcs
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 ?
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Data member with same name as enclosing class
1999-01-21 18:29 ` Jason Merrill
@ 1999-01-31 23:58 ` Jason Merrill
0 siblings, 0 replies; 20+ messages in thread
From: Jason Merrill @ 1999-01-31 23:58 UTC (permalink / raw)
To: Martin v. Loewis; +Cc: egcs
>>>>> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Data member with same name as enclosing class
1999-01-21 9:07 ` Gabriel Dos Reis
@ 1999-01-31 23:58 ` Gabriel Dos Reis
0 siblings, 0 replies; 20+ messages in thread
From: Gabriel Dos Reis @ 1999-01-31 23:58 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: Martin v. Loewis, Klaus.Kaempf, egcs
>>>>> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Data member with same name as enclosing class
1999-01-21 15:08 ` Martin v. Loewis
1999-01-21 18:29 ` Jason Merrill
@ 1999-01-31 23:58 ` Martin v. Loewis
1 sibling, 0 replies; 20+ messages in thread
From: Martin v. Loewis @ 1999-01-31 23:58 UTC (permalink / raw)
To: jason; +Cc: egcs
> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Data member with same name as enclosing class
1999-01-31 23:58 Data member with same name as enclosing class Klaus Kaempf
[not found] ` <199901202031.VAA00823.cygnus.egcs@mira.isdn.cs.tu-berlin.de>
@ 1999-01-31 23:58 ` Martin v. Loewis
1999-01-21 8:37 ` Matthias Urlichs
1 sibling, 1 reply; 20+ messages in thread
From: Martin v. Loewis @ 1999-01-31 23:58 UTC (permalink / raw)
To: Klaus.Kaempf; +Cc: egcs
> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Data member with same name as enclosing class
1999-01-21 1:05 ` Jason Merrill
1999-01-21 15:08 ` Martin v. Loewis
@ 1999-01-31 23:58 ` Jason Merrill
1 sibling, 0 replies; 20+ messages in thread
From: Jason Merrill @ 1999-01-31 23:58 UTC (permalink / raw)
To: Martin v. Loewis, egcs
>>>>> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Data member with same name as enclosing class
1999-01-21 15:08 ` Martin v. Loewis
@ 1999-01-31 23:58 ` Martin v. Loewis
0 siblings, 0 replies; 20+ messages in thread
From: Martin v. Loewis @ 1999-01-31 23:58 UTC (permalink / raw)
To: Klaus.Kaempf; +Cc: smurf, Gabriel.Dos-Reis, egcs
> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Data member with same name as enclosing class
1999-01-21 10:56 ` Andi Kleen
@ 1999-01-31 23:58 ` Andi Kleen
0 siblings, 0 replies; 20+ messages in thread
From: Andi Kleen @ 1999-01-31 23:58 UTC (permalink / raw)
To: Klaus Kaempf; +Cc: egcs
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Data member with same name as enclosing class
1999-01-21 9:14 Klaus Kaempf
` (2 preceding siblings ...)
1999-01-21 15:08 ` Martin v. Loewis
@ 1999-01-31 23:58 ` Klaus Kaempf
3 siblings, 0 replies; 20+ messages in thread
From: Klaus Kaempf @ 1999-01-31 23:58 UTC (permalink / raw)
To: Matthias Urlichs, Gabriel Dos Reis; +Cc: Martin v. Loewis, egcs
>>> > 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 ?!
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Data member with same name as enclosing class
1999-01-21 12:32 ` Jason Merrill
@ 1999-01-31 23:58 ` Jason Merrill
0 siblings, 0 replies; 20+ messages in thread
From: Jason Merrill @ 1999-01-31 23:58 UTC (permalink / raw)
To: Andi Kleen, egcs
>>>>> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Data member with same name as enclosing class
1999-01-21 9:14 Klaus Kaempf
1999-01-21 10:56 ` Andi Kleen
[not found] ` <m3d848bgl5.fsf.cygnus.egcs@fred.muc.de>
@ 1999-01-21 15:08 ` Martin v. Loewis
1999-01-31 23:58 ` Martin v. Loewis
1999-01-31 23:58 ` Klaus Kaempf
3 siblings, 1 reply; 20+ messages in thread
From: Martin v. Loewis @ 1999-01-21 15:08 UTC (permalink / raw)
To: Klaus.Kaempf; +Cc: smurf, Gabriel.Dos-Reis, egcs
> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Data member with same name as enclosing class
[not found] ` <m3d848bgl5.fsf.cygnus.egcs@fred.muc.de>
@ 1999-01-21 12:32 ` Jason Merrill
1999-01-31 23:58 ` Jason Merrill
0 siblings, 1 reply; 20+ messages in thread
From: Jason Merrill @ 1999-01-21 12:32 UTC (permalink / raw)
To: Andi Kleen, egcs
>>>>> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Data member with same name as enclosing class
1999-01-21 9:14 Klaus Kaempf
@ 1999-01-21 10:56 ` Andi Kleen
1999-01-31 23:58 ` Andi Kleen
[not found] ` <m3d848bgl5.fsf.cygnus.egcs@fred.muc.de>
` (2 subsequent siblings)
3 siblings, 1 reply; 20+ messages in thread
From: Andi Kleen @ 1999-01-21 10:56 UTC (permalink / raw)
To: Klaus Kaempf; +Cc: egcs
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Data member with same name as enclosing class
@ 1999-01-21 9:14 Klaus Kaempf
1999-01-21 10:56 ` Andi Kleen
` (3 more replies)
0 siblings, 4 replies; 20+ messages in thread
From: Klaus Kaempf @ 1999-01-21 9:14 UTC (permalink / raw)
To: Matthias Urlichs, Gabriel Dos Reis; +Cc: Martin v. Loewis, egcs
>>> > 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 ?!
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~1999-01-31 23:58 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-01-31 23:58 Data member with same name as enclosing class Klaus Kaempf
[not found] ` <199901202031.VAA00823.cygnus.egcs@mira.isdn.cs.tu-berlin.de>
1999-01-21 1:05 ` Jason Merrill
1999-01-21 15:08 ` Martin v. Loewis
1999-01-21 18:29 ` Jason Merrill
1999-01-31 23:58 ` Jason Merrill
1999-01-31 23:58 ` Martin v. Loewis
1999-01-31 23:58 ` Jason Merrill
1999-01-31 23:58 ` Martin v. Loewis
1999-01-21 8:37 ` Matthias Urlichs
1999-01-21 9:07 ` Gabriel Dos Reis
1999-01-31 23:58 ` Gabriel Dos Reis
1999-01-31 23:58 ` Matthias Urlichs
-- strict thread matches above, loose matches on Subject: below --
1999-01-21 9:14 Klaus Kaempf
1999-01-21 10:56 ` Andi Kleen
1999-01-31 23:58 ` Andi Kleen
[not found] ` <m3d848bgl5.fsf.cygnus.egcs@fred.muc.de>
1999-01-21 12:32 ` Jason Merrill
1999-01-31 23:58 ` Jason Merrill
1999-01-21 15:08 ` Martin v. Loewis
1999-01-31 23:58 ` Martin v. Loewis
1999-01-31 23:58 ` Klaus Kaempf
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).