CODEWITHSUNDEEP
c++gccwarningsglew
JohanLejdung
JohanLejdung

Reputation: 363

GCC compiler warning overflow

EDIT: I found a way to disable the warnings from third-party codes using GCC. Look at this post right here: http://sphaleron.blogspot.se/2011/06/ignoring-gcc-warnings-on-per-file-basis.html Or as bames53 post said!

I've just upgraded my GCC compiler and all of a sudden I got loads of warnings I never had before. Basically everyone of them is a conversion from int to Sin16 when I don't specify that it should be Sint16.

This example below should throw such a warning:

int number = 6;
SDL_Rect rect = {number, number, number, number};

SDL_Rect expects a Sint16 as input. Anyway, I was starting to fix these warnings (because why not?) when I checked for new ones and to my surprise I received over 100 warnings from the glew file I added to be able to draw with OpenGL more efficiently. I have no plans to go into that code just to fix warnings.

What would you have done? How important is this? If I don't fix them is there a way for me to remove these warnings?

Clarification: I always fix more severe warnings, it's just that all the warnings from my code are Narrowing warnings (in glew.c it's "warning: 'variable' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]|") and I'm wondering how important it is to fix these, especially since glew threw a whole bunch at me.

Upvotes: 1

Views: 3046

Answers (3)

jerry
jerry

Reputation: 2611

You can use make to compile only glew.c with the option -Wno-attributes. If you really don't care about any warnings from that file, use -w (note that this is a lower case w).

A very simple makefile follows. Note that each command line starts with a horizontal tab \t and # starts a comment.

# invoke with "make" or "make all"
all : main.o other.o glew.o  
    g++ -o projectName main.o other.o glew.o -pedantic -Wall -Wextra -Werror

main.o : main.c other.h glew.h
    g++ -c main.c -pedantic -Wall -Wextra -Werror

other.o : other.c other.h
    g++ -c other.c -pedantic -Wall -Wextra -Werror

glew.o : glew.c glew.h
    g++ -c glew.c -Wall -Wno-attributes
    # alternatively, you might want something like one of the following:
    # g++ -c glew.c -Wno-attributes
    # g++ -c glew.c -w

# use "make clean" to remove the executable and intermediate files
clean :
    rm projectName *.o

There's a lot more you can do (see the make manual). There are even tools which will automatically create the makefile for you.

Upvotes: 1

bames53
bames53

Reputation: 88155

Your project should always be warning free. Setting your compiler to treat warnings as errors is a good way to encourage developers to maintain a warning free state, although you have to watch and make sure warnings which should be fixed don't get disabled simply because that's easier at a certain moment in time. Disabling a warning should require review.

Any warnings that cannot be fixed, because they are in third party headers or otherwise, should be silenced. Otherwise they add noise to the output that can hide warnings that you can and should fix.

If the source of a warning is relatively localized you can disable it for just that location in the source:

// VC++
#pragma warning(push)
#pragma warning( disable : 4507 34)
#include <third_party_header.h>
#pragma warning(pop)

// clang
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wmultichar"
#include <third_party_header.h>
#pragma clang diagnostic pop

// GCC
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wuninitialized"
#include <third_party_header.h>
#pragma GCC diagnostic pop

If a warning occurs in many places and you can't fix them because they're false positives of some sort you may consider disabling the warning across the whole project (or possibly for a module) with compiler flags

VC++: /wd4507

GCC/clang: -Wno-uninitialized

You should also periodically reevaluate all disabled warnings to ensure that the reasons for disabling them are still valid as the codebase and toolchain evolve. Also look for new warnings introduced that you can enable.

clang has a useful tool for discovering new warnings; the -Weverything flag. On both GCC and clang -Wall actually only enables a subset of warnings that the compiler developers see as broadly applicable and with relatively strict false positive requirements; basically it's just a good default set of warnings. -Weverything enables literally every warning the compiler offers.

Rather than using an 'additive' strategy for warnings, where you read compiler documentation, choose warnings to enable as seems good to you, I like to use a 'subtractive' strategy with -Weverything combined with a list of -Wno-* flags. This way new warnings get used automatically. Just remember to reevaluate disabled warnings periodically, so that if a warning you previously didn't find useful improves you'll see the improvement and be able to use it.

Upvotes: 3

mah
mah

Reputation: 39807

What would you have done? I would have fixed them if they were my source files, and ignored them if they are external code that I have no influence/interest into the development of.

How important is this? That depends on your priorities... but not fixing them probably won't make the code not run. However, it's bad practice and it can cause you to miss more important warnings in the future. The more warnings you have, and the more active development on files with warnings are, the more useful it is to clean them up. If there is a good reason to not fix them (like it's 3rd party code... "too much work" is not a good reason in itself), I would move the related code to a sub-project designated as warning-laden so that I could concentrate on my own work warning-free.

If i dont fix them is there a way for me to remove these warnings? Sounds like downgrading your compiler will do it.

Upvotes: 2

Related Questions