13

We want to start using -Wall -Werror on a large project.
Due to the size, this change has to be phased, and we want to start with the most important warnings first.

The best way to do it seems to be using -Wall -Werror, with exceptions for specific warnings. The exceptional warnings are those which we have a lot of (so fixing them all is hard and risky), and we don't consider them very dangerous.
I'm not saying we don't want to fix all these warnings - just not on the first phase.

I know two ways to exclude a warning from -Werror - the best is -Wno-error=xxx, and if it doesn't work - -Wno-xxx (of course, we prefer to see the warning and ignore it, rather than hide it).

My problem is with warnings which are enabled by default, and don't have a -Wxxx flag related to them. I couldn't find any way to alllow them when -Werror is used.

I'm specifically concerned about two specific warnings. Here's a program that exhibits them and the compiler output:

#include <stdio.h>
void f(int *p) { printf("%p\n", p); }

int main(int argc, char *argv[]) {
        const int *p = NULL;
        const unsigned int *q = NULL;
        f(p);           /* Line 7: p is const, f expects non const */
        if (p == q) {   /* Line 8: p is signed, q is unsigned */
                printf("Both NULL\n");
        }
        return 0;
}

% gcc warn.c
warn.c: In function 'main':
warn.c:7: warning: passing argument 1 of 'f' discards qualifiers from pointer target type
warn.c:8: warning: comparison of distinct pointer types lacks a cast

I know the best solution is to fix these warnings, but it's much easier said than done. In order for this change to be successful, we have to do this phased, and can't do too many changes at once.

Any suggestions? Thanks.

ugoren
  • 16,023
  • 3
  • 35
  • 65
  • 1
    What about doing it the other way around, i.e. enable `-Wall` globally, and `-Werror` only on the parts of the code you've "cleansed"? – Mat Apr 30 '13 at 14:01
  • related: http://stackoverflow.com/questions/12163969/how-to-eliminate-the-discard-qualifier-warning – Nate Kohl Apr 30 '13 at 14:03
  • 2
    @H2CO3 He said he's going to fix it, but in a large project I can see not wanting to deal with that first. No need to treat him like a child and keep something from him. – Dan Fego Apr 30 '13 at 14:05
  • @Mat, it's possible. But then I'd forget some warnings, or some would be added, and they'd be ignored. – ugoren Apr 30 '13 at 14:06
  • 2
    @H2CO3, Const correctness is a great thing, but very hard to reach in a big project, if it was neglected over years of development. To fix one simple warning, you end up changing tens of functions, which is at present out of the question. – ugoren Apr 30 '13 at 14:08
  • 1
    @ugoren: not really. As long as you've got `-Wall` all over the place and you log your build output, a simple `grep` will tell you all the warnings you haven't fixed yet. – Mat Apr 30 '13 at 14:12
  • 1
    @ugoren "Const correctness is great but hard to reach in a big project" - hm, maybe it's just me, but I'm making a scripting language parser and interpreter, it's nearly 5000 LOC and I expanding, and I managed to get no warnings and maintain const correctness. –  Apr 30 '13 at 14:21
  • 1
    @Mat: It can be too difficult to do politically (to go in and change all the warnings at) — believe me, I've been there, done that! I agree 100% with your `-Wall` without `-Werror` as the interim step. That is the way I was forced to handle it (in fact, even the cleansed code couldn't readily be made to add `-Werror`; that was a side-effect of a sub-adequate build system). 'Tis painful, but it really can happen like that in large code bases. – Jonathan Leffler Apr 30 '13 at 14:23
  • 1
    @H2CO3: 5000 LOC? That's not a big project; 20,000 files ranging from 1-30 KLOC per file is a big project. Some of the files would be 30 years old, too. – Jonathan Leffler Apr 30 '13 at 14:25
  • @JonathanLeffler Maybe not that big, but not even a huge code base is a good excuse for writing bad code. –  Apr 30 '13 at 14:27
  • @Mat, In principle you're right - finding warnings after compilation can be used instead of `-Werror`. But it isn't such a simple grep if you want to allow some warnings and forbid others. Also it's easier for a full build, but a developer compiling a few files is also important (if we don't fail his make, he'll commit his code). – ugoren Apr 30 '13 at 14:28
  • 1
    @H2CO3: if you don't think there are large codebases out there that have files that pre-date even C89, and that still need to be maintained, you're in for surprises. OP didn't write all that code. Fixing it all can be a huge expense. – Mat Apr 30 '13 at 14:30
  • 2
    @H2CO3, starting with const correctness and keeping it as you go is great. But I'm talking about a huge project, where it was neglected for awfully long. You can't fix it in a day. – ugoren Apr 30 '13 at 14:31
  • Not sure whether Mat's »`-Werror` only on the parts of the code you've "cleansed"« was meant per-file or per-warning. If the former, is `-Wall -Werror=xyz` an option? Undoubtedly a tedious one if at all, but... – Daniel Fischer Apr 30 '13 at 14:51
  • @DanielFischer, I was thinking per warning. It's an option, but a bad one. One problem with it is warnings which have no flag (just like those mentioned here, but other ones, which I really want to be treated as errors). – ugoren Apr 30 '13 at 19:15
  • Yes, one would want something better and only resort to that if one finds nothing better. But I thought it's better to mention it than not even taking it into consideration. Unfortunately, I have no better idea :( – Daniel Fischer Apr 30 '13 at 19:18
  • this appears to be answered here: http://stackoverflow.com/questions/925179/selectively-removing-warning – levengli May 06 '13 at 11:48
  • @levengli, Thanks, but it's not exactly this. It works for warnings which have a specific flag (like `-Wuninitialized`), but not for warnings that are enabled by default. – ugoren May 06 '13 at 12:14
  • I believe this question is very similar to yours. http://stackoverflow.com/questions/3378560/how-to-disable-gcc-warnings-for-a-few-lines-of-code – Felype May 09 '13 at 17:41
  • Thanks @Felype, but it refers to warnings that have a specific flag controlling them, while my problem is with ones enabled by default. – ugoren May 10 '13 at 07:49

3 Answers3

1

What about phasing on a compilation unit/module/library basis instead of per warning? Is triggering a subtarget compilation an option (a good-enough build system in place)?

Blazor
  • 171
  • 4
  • 11
  • Phasing by module isn't so helpful. It will take a long time until we manage to have the important warnings enabled throughout our code this way. An I'm not sure what you mean by triggering a subtarget compilation. – ugoren May 10 '13 at 21:13
  • That's right, it will take a long time, but since what you're asking in the post is **not** possible (disabling built-in warnings enabled by -Wall), the problem becomes how to filter the output in such a way as to make it reasonable to work with. If you work on a module basis, you can cope with all the warnings at once, because they will be inherent to a much smaller code base. Just my two cents. – Blazor May 11 '13 at 14:31
0

It might be folly, but ...

Why not a simple grep ?

something like 

 gcc teste.c 2>&1 | grep -v 'comparison of distinct' | grep -v 'some_other_string'

You probably want to hide these greps in a script, and call the script from your makefile instead of gcc

josinalvo
  • 1,366
  • 13
  • 26
  • Another suggestion: run at least a full count of warnings with wc -l, to ensure you are not adding new warnings that are being filtered out – josinalvo May 21 '13 at 15:25
  • It's all very well for a simple compilation. But with a complicated project, lots of developers, platforms, compilation methods, this approach gets quite difficult. – ugoren May 22 '13 at 10:09
  • @ugoren "lots of compilation methods"?? If not everyone is using the same build system then you may have bigger problems to deal with. – M.M Nov 05 '14 at 01:19
  • 1
    @MattMcNabb, We have bigger problems, but they're to complicated to post here. It doesn't mean we shouldn't solve the small ones. – ugoren Nov 05 '14 at 10:18
0

According to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43245 it will be "-Wdiscarded-qualifiers", but since the bug-fixed entry is from May 1, 2014, the gcc compiler you are using might not support it.

Günter Fuchs
  • 21
  • 2