headers
Stephan Kulow | 1 Nov 2005 09:58
Picon
Favicon
Gravatar

Re: RFC: Avoiding #warning (C/C++ preprocessor extension)

On Monday 31 October 2005 22:34, Frans Englich wrote:
> The world is way too complex, someone should rewrite it. I who thought it
> was even worth a try to clean up kdelibs and freeze it with -Werror :(

Sure it is, but that does not mean you should commit the flag. Most warnings I 
leave in the code are reminders on someone else to pick it up. Like we have
tons of unused name arguments - that are there to be removed. But if someone
will compile with -Werror, he will take the easy way out and remove the 
parameter name so that gcc shuts up. That's not the purpose, but that's what 
happening if you compile with -Werror.

And SUSE had to remove -Werror from all well intended KDE packages because
gcc4 decided Qt needs way more virtual destructors and warns about it in -Wall
now. Just too bad that adding them to Qt3 is binary incompatible. So good bye
-Werror

Greetings, Stephan
Permalink | Reply |
headers
Frans Englich | 1 Nov 2005 17:22
Picon

Re: RFC: Avoiding #warning (C/C++ preprocessor extension)

On Tuesday 01 November 2005 08:58, Stephan Kulow wrote:
> On Monday 31 October 2005 22:34, Frans Englich wrote:
> > The world is way too complex, someone should rewrite it. I who thought it
> > was even worth a try to clean up kdelibs and freeze it with -Werror :(
>
> Sure it is, but that does not mean you should commit the flag. Most
> warnings I leave in the code are reminders on someone else to pick it up.
> Like we have tons of unused name arguments - that are there to be removed.
> But if someone will compile with -Werror, he will take the easy way out and
> remove the parameter name so that gcc shuts up. That's not the purpose, but
> that's what happening if you compile with -Werror.

Yes, that's counterproductive. I'd say that the current state of trunk, these 
large refactorings, are exceptional circumstances which, yes, -Werror doesn't 
work for. I think that's ok, just as it's ok to commit code that introduce 
temporary test regressions, as cause of a large overhaul/rewrite.

However, "if someone will compile with -Werror, he will take the easy way out 
and remove the parameter name so that gcc shuts up" wouldn't occur in the 
normal case, because overhauls wouldn't be necessary -- each change going in 
would be an atomic, clean commit, introducing no warnings. Assuming -Werror 
was a good idea overall, that is.

>
> And SUSE had to remove -Werror from all well intended KDE packages because
> gcc4 decided Qt needs way more virtual destructors and warns about it in
> -Wall now. Just too bad that adding them to Qt3 is binary incompatible. So
> good bye -Werror

Yupp :} to quote Mark Mitchell:
(Continue reading)

Permalink | Reply |
headers
Martijn Klingens | 1 Nov 2005 13:26
Picon
Favicon

Re: RFC: Avoiding #warning (C/C++ preprocessor extension)

On Tuesday 01 November 2005 09:58, Stephan Kulow wrote:
> And SUSE had to remove -Werror from all well intended KDE packages because
> gcc4 decided Qt needs way more virtual destructors and warns about it in
> -Wall now. Just too bad that adding them to Qt3 is binary incompatible. So
> good bye -Werror

Doesn't it work if you patch the failing Qt includes with '#pragma GCC 
system_header'? AFAICS that shouldn't affect BC and should suppress the 
warnings and hence the -Werror traps.

See http://gcc.gnu.org/onlinedocs/gcc-3.2.3/cpp/Pragmas.html

--

-- 
Martijn
Permalink | Reply |
headers
Nicolas Goutte | 1 Nov 2005 16:57
Picon

Re: RFC: Avoiding #warning (C/C++ preprocessor extension)

On Tuesday 01 November 2005 13:26, Martijn Klingens wrote:
> On Tuesday 01 November 2005 09:58, Stephan Kulow wrote:
> > And SUSE had to remove -Werror from all well intended KDE packages
> > because gcc4 decided Qt needs way more virtual destructors and warns
> > about it in -Wall now. Just too bad that adding them to Qt3 is binary
> > incompatible. So good bye -Werror
>
> Doesn't it work if you patch the failing Qt includes with '#pragma GCC
> system_header'? AFAICS that shouldn't affect BC and should suppress the
> warnings and hence the -Werror traps.

That is the kind of things I meant. You have to add a gcc-ism to keep the 
compiler calm. But we are supposed to make *portable* code!

I do not think that extra #ifs are better than warnings. (I would even think 
the contrary, as it makes the code less readable.)

>
> See http://gcc.gnu.org/onlinedocs/gcc-3.2.3/cpp/Pragmas.html

Have a nice day!
Permalink | Reply |
headers
Martijn Klingens | 1 Nov 2005 17:15
Picon
Favicon

Re: RFC: Avoiding #warning (C/C++ preprocessor extension)

On Tuesday 01 November 2005 16:57, Nicolas Goutte wrote:
> On Tuesday 01 November 2005 13:26, Martijn Klingens wrote:
> > Doesn't it work if you patch the failing Qt includes with '#pragma GCC
> > system_header'? AFAICS that shouldn't affect BC and should suppress the
> > warnings and hence the -Werror traps.
>
> That is the kind of things I meant. You have to add a gcc-ism to keep the
> compiler calm. But we are supposed to make *portable* code!

C'mon, don't cry wolf.

-Werror is a gcc-ism too. It's part of the compiler flags just as much as 
-pedantic is, and even in the hypothetical case where we would start to use 
it globally it would only be enabled on gcc, not affecting portability in the 
least.

While I don't agree with having it on unconditionally your reasoning is still 
wrong.

> I do not think that extra #ifs are better than warnings. (I would even
> think the contrary, as it makes the code less readable.)

Please read the thread more carefully -- this part was about turning warnings 
into errors, and was talking about ALL warnings, including those that the 
compiler generates itself. It was a sidestep from the #warning discussion and 
has little to do with it anymore.

--

-- 
Martijn
(Continue reading)

Permalink | Reply |
headers
Nicolas Goutte | 1 Nov 2005 17:33
Picon

Re: RFC: Avoiding #warning (C/C++ preprocessor extension)

On Tuesday 01 November 2005 17:15, Martijn Klingens wrote:
> On Tuesday 01 November 2005 16:57, Nicolas Goutte wrote:
> > On Tuesday 01 November 2005 13:26, Martijn Klingens wrote:
> > > Doesn't it work if you patch the failing Qt includes with '#pragma GCC
> > > system_header'? AFAICS that shouldn't affect BC and should suppress the
> > > warnings and hence the -Werror traps.
> >
> > That is the kind of things I meant. You have to add a gcc-ism to keep the
> > compiler calm. But we are supposed to make *portable* code!
>
> C'mon, don't cry wolf.
>
> -Werror is a gcc-ism too. 

Perhaps the exact name of the flag, but not the function.

In an old C compiler, it could have a sence even, as lint was a separate 
program.

It can have a sence in compiler like MSVC which can control easily the 
importance level of warnings. (That is the only thing that I miss from that 
compiler in GCC.) So when you want to check seriously, you can force warnings 
of "maximal level 2" (of 4 levels) and force the "warning-is-error" function.
And in normal development, you use all 4 warning levels without forcing them 
as errors.

(Again, disclaimer: I used MSVC years ago, so it could be well, that this 
compiler has changed much in the meantime.)

(...)
(Continue reading)

Permalink | Reply |
headers
Stephan Kulow | 1 Nov 2005 13:32
Picon
Favicon
Gravatar

Re: RFC: Avoiding #warning (C/C++ preprocessor extension)

On Tuesday 01 November 2005 13:26, Martijn Klingens wrote:
> On Tuesday 01 November 2005 09:58, Stephan Kulow wrote:
> > And SUSE had to remove -Werror from all well intended KDE packages
> > because gcc4 decided Qt needs way more virtual destructors and warns
> > about it in -Wall now. Just too bad that adding them to Qt3 is binary
> > incompatible. So good bye -Werror
>
> Doesn't it work if you patch the failing Qt includes with '#pragma GCC
> system_header'? AFAICS that shouldn't affect BC and should suppress the
> warnings and hence the -Werror traps.
>
Yeah, that's the kind of work arounds I talked about - qt-copy has the patch
from SUSE though.

Greetings, Stephan
Permalink | Reply |

Gmane