I presume that the C++ standard requires this to be an error: int foo(int arg){ goto Hell; int i = arg; Hell: return arg; // or using i here } Especially in the case of plain old data (no constructor, etc.) this behavior is needlessly incompatible with C. Please require -pedantic -std=c++98 for such unfriendly behavior.
First what version of GCC you are using? Is it before 4.0.3? If so this is a dup of bug 20721.
Please read http://gcc.gnu.org/bugs.html and provide all the information there which in case means the version of gcc.
I saw it on Fedora Core 5, which I believe is gcc 4.1, and I saw it on a gcc which describes itself as: gcc version 4.0.3 (Debian 4.0.3-1) So that is two rather different gcc versions. One is x86-64, the other is 32-bit PowerPC. Am I wrong to assume that the latest gcc behaves this way?
What exactly do you want, no error unless you supply -std=c++98 -pedantic. that is not going to change sorry.
No legal C++ code would break if g++ were less incompatible with C. Why be incompatible? There are cases where gcc takes far greater liberties with the standards, breaking fully legal code. (trigraphs for example) The proposed change would allow for easier reuse of C code, which is certainly a benefit. If the new rule is to follow standards to the letter by default, then trigraphs are an urgent need. Otherwise, the goto behavior should change. I don't see how it is justified to break valid code, yet refuse a change that would allow greater compatibility with C.
GCC is not going to implement by default a non standard version of C++ (well some extensions are on by default but those are usually more defined than this).
I think this is a valid request. While random language extensions aren't useful, compatibility with C99 is. Maybe somebody else can comment on this...
(In reply to comment #7) > I think this is a valid request. While random language extensions aren't > useful, > compatibility with C99 is. Maybe somebody else can comment on this... There are a lot of differences between C and C++, this is just one of the differences. Another would be where the variable is done inside a for/if expression in that: int g(void); int f(void) { if (int t = g()) { int t = g()+1; } } is valid C but invalid C++ (though GCC gets it wrong for C++ but that is an already filed bug report). PR 27252 (aka PR 9278) is another example where C and C++ diff and in fact was just fixed for 4.2.0 for a bug report. These are just some examples of where C and C++ differ.
Regarding Comment #8: Of course I do not want g++ to be a perfect superset of gcc. That is unreasonable, because it would break legitimate standards-conforming C++ code. I only ask that C compatibility be provided for code that would otherwise fail to compile as C++. This makes code reuse much easier.
(In reply to comment #9) > I only ask that C compatibility be provided for code that would otherwise fail > to compile as C++. This makes code reuse much easier. I showed two other examples which are (were) reproted saying GCC accepted invalid C++ (and the code was valid C and people actually used the second case already in patricte which is why I pointed it out). So if you want to modify the C++ front-end and to make an option, that is fine but GCC should (and does have) a pratice of not accepting new extensions.
When did gcc suddenly stop accepting new extensions? For years gcc has been more of a practical real-world compiler than a pedantic standards-only compiler. Many extensions have been added, both useful and useless. Just look at the list of them. Much of gcc's popularity has historically had to do with making things easy for programmers. Don't let us down now that the alternatives have gone extinct.
Subject: Re: goto crossing P.O.D. initialization "falk at debian dot org" <gcc-bugzilla@gcc.gnu.org> writes: | I think this is a valid request. While random language extensions aren't | useful, | compatibility with C99 is. Maybe somebody else can comment on this... You have to be more precise about what you mean by C99 compatibility. My take on this goto stuff, if it is not valid C++, it is valid C++. Period. -- Gaby
Subject: Re: goto crossing P.O.D. initialization "pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: | PR 27252 (aka PR 9278) is another example where C and C++ diff and in fact was | just fixed for 4.2.0 for a bug report. These are just some examples of where C | and C++ differ. I fully agree. People have to be extra careful when they talk about compatibility with C99 where the C committee has carefully chosen to depart from C++. -- Gaby
Subject: Re: goto crossing P.O.D. initialization "acahalan at gmail dot com" <gcc-bugzilla@gcc.gnu.org> writes: | I only ask that C compatibility be provided for code that would otherwise fail | to compile as C++. This makes code reuse much easier. Given prior existence in C++, I think logic would require that you ask gcc to be compatibile with g++. -- Gaby
(In reply to comment #12) > Subject: Re: goto crossing P.O.D. initialization > > "falk at debian dot org" <gcc-bugzilla@gcc.gnu.org> writes: > > | I think this is a valid request. While random language extensions aren't > | useful, > | compatibility with C99 is. Maybe somebody else can comment on this... > > You have to be more precise about what you mean by C99 compatibility. I have trouble seeing what might be unclear about this term. I mean that code that is valid C99 is accepted in C++ unless there is a good reason not to. just like most of C89 is accepted in C++ unless there is a good reason not to. > My take on this goto stuff, if it is not valid C++, it is valid C++. That logically implies that everything valid C++, which might be overdoing it a bit ;-)
Subject: Re: goto crossing P.O.D. initialization "falk at debian dot org" <gcc-bugzilla@gcc.gnu.org> writes: | ------- Comment #15 from falk at debian dot org 2006-05-01 20:55 ------- | (In reply to comment #12) | > Subject: Re: goto crossing P.O.D. initialization | > | > "falk at debian dot org" <gcc-bugzilla@gcc.gnu.org> writes: | > | > | I think this is a valid request. While random language extensions aren't | > | useful, | > | compatibility with C99 is. Maybe somebody else can comment on this... | > | > You have to be more precise about what you mean by C99 compatibility. | | I have trouble seeing what might be unclear about this term. I suspect part of the problem is that everybody believes that his/her uses of the term are so clear that they he/she has trouble seeing anybody disagree with him/her. | I mean that code | that is valid C99 is accepted in C++ unless there is a good reason not to. And why not the other way around? I mean, codes that is valid C++ is accepted in C99 unless there is good reason not to. As far as I can see, that also is compatibility. | just like most of C89 is accepted in C++ unless there is a good reason not to. I suspect this is might be one the places things needs to be explained. If * only a subset of C89 is valid C++ and has same meaning as in C++, * C99 has carefully departed from both C89 and C++ why is it that "code that is valid C99 is accepted C++ unless there is a good reason not to"? -- Gaby