This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: -Wno-return-type doesn't seem to work.


> 1) When the option -Wno-return-type is completely ineffective, then
>    why does it exist?

Historic reasons. gcc 2.95 is the first compiler that enforces the
rule. Feedback may result in reverting the feature, if enough people
complain and give good reasons for expecting a C++ compiler not to
issue those diagnostics mandated by the C++ standard.

The option is inherited from C, and people may have it in their
makefiles; an option shouldn't be removed without advance warning.

> 2) Agreed. But when you are beginning to stop taking care about the
>    problems caused by the imperfect world of vendor-Unices, then what
>    does this line in the source:
> 
> 	  if (in_system_header)
> 	    /* Allow it, sigh.  */;

Well, you have to live with compromises. It was certainly not intended
to break compilation on Solaris - and compilation on Solaris does
indeed not break. That you get all those warnings is a side effect -
perhaps unfortunate, but not worth violating the C++ standard forever.

> 3) When the new direction of gcc is to enforce standard behaviour to
>    the rest of the world, then there should be no need for fixinclude.
>    Otherwise fixinclude might also be a place where this long standing
>    problem might be avoided.

It is not a new direction, and not at all for gcc. There is a C
compiler in GCC, and that should certainly continue to compile code
that was written B.C. And there is a C++ compiler, which tries to
implement a recently adopted standard. What is so difficult to
understand?

> I'd change that when you include the fix in the next release. I always
> thought that's why I have the source: To fix or improve something and
> share that.

I recall there was a proposal to fixinclude the X11 headers; you may
search the email archives for the discussion on the change.

I personally feel that this is a change to the better. Having optional
return types makes the compiler more difficult to implement; being
able to remove that additional complexity makes it more maintainable.
Language specifications aren't just there for fun.

Regards,
Martin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]