4 ms·

I see questions online all the time that make me wonder just how old the compiler being used is. Modern versions of GCC, Clang and Visual Studio all have warni

by Ogre 14y ago

I see questions online all the time that make me wonder just how old the compiler being used is. Modern versions of GCC, Clang and Visual Studio all have warnings enabled by default for an awful lot of valid, but probably wrong, code. Apparently people learning to code are somehow winding up on old compilers much more often than those of us who have been writing C and C++ for a long time. Or, I guess, the people having problems learning to code are the people who happen to be on ancient compilers. Maybe it's not so surprising after all.

jlgreco 14y ago
Compilers from the CD-ROMs in the back of ancient programming books from libraries maybe?
cube13 14y ago
It might be the default settings on the compilers as well. I believe that in our environment, we set our warning level higher than the default, because a lot of the warnings(signed/unsigned mismatch, 32/64-bit pointers, etc.) can be an indication of an actual bug.
Someone 14y ago
I think it is more likely something like this: Many C programmers cannot make valid judgments as to the severity of a warning ('warning: bla bla may ...' => does it or doesn't it? I wouldn't know) Also, those programmers typically would not know how to change their code to get rid of warnings. If they do, or if their compiler shoves a solution in their face (for example, a compiler might suggest to do "if((y=f(x)))") to get rid of an 'assignment inside if' warning), they do not see the advantage of the extra work. The end result is code that produces hundreds of warnings. If a code change brings in a new one, people don't notice and/or don't care. Some IDEs make things worse by allowing you to filter out warnings and messages from their output, so that you can focus on compiler errors. That is good for good programmers (they will fix errors, compile again, and then study every single warning), but bad for those who are happy to have code that compiles at all, as they will run into 'do not show me warnings' mode.
- npsimons 14y ago
  The first reaction to an unfamiliar warning in any language should be to consult the manual (or Google it). In the case of VisualStudio at least, this is trivial (these days) due to the warning numbers you can paste into Google and usually get not just an explanation, but a way to fix it (usually via SO). Really, if a programmer can't fix warnings (and that includes taking the time to learn why they are there), what are you paying them for? My policy on projects I work on is to enable all warnings, treat them as errors, then only disable warnings after trying to fix them, researching them, and finally discussing them, and usually then only on a case by case basis (only occasionally do I eschew certain warnings altogether (such as -Waggregate-return for g++), and I leave them commented out with the reason they are disbled). (Edit: a quick tip for gcc, BTW: use -fdiagnostic-show-option for easier search of a warning, and the name of it in case you have to pragma it out).
marcosdumay 14y ago
I've just tried it. That code compiles without warnings by the default configuration of gcc version 4.4.5 (Debian 4.4.5-8) in my desktop (it's an up-to-date Debian Stable install). If the default settings of gcc included throuwing out warnings for every time a function is declared without parameters and missing the void, lots of people would complain, and loud. It's a very common construct.
- kelnos 14y ago
  Wow, that's crazy. I just tried it too (gcc 4.6.3). No warning options generate no warnings at all. -Wall only warns about the lack of return statement in main(). You only get the parameter-type default warning if you add -Wextra. Interestingly, adding -std=c99 oddly removes the warning about the missing return statement in main(). I can't find a way to warn about the empty param list in the prototype, but it's possible that it's just not considered "bad enough style" to warrant one. C++ is, of course, more strict. Try to compile that with g++, and you get several errors. The compiler needs to know how to mangle the symbol when it first encounters it, so you can't have "unspecified" parameter lists anywhere.

by Ogre 14y ago

jlgreco 14y ago

Compilers from the CD-ROMs in the back of ancient programming books from libraries maybe?

cube13 14y ago

It might be the default settings on the compilers as well. I believe that in our environment, we set our warning level higher than the default, because a lot of the warnings(signed/unsigned mismatch, 32/64-bit pointers, etc.) can be an indication of an actual bug.

Someone 14y ago

I think it is more likely something like this: Many C programmers cannot make valid judgments as to the severity of a warning ('warning: bla bla may ...' => does it or doesn't it? I wouldn't know) Also, those programmers typically would not know how to change their code to get rid of warnings. If they do, or if their compiler shoves a solution in their face (for example, a compiler might suggest to do "if((y=f(x)))") to get rid of an 'assignment inside if' warning), they do not see the advantage of the extra work. The end result is code that produces hundreds of warnings. If a code change brings in a new one, people don't notice and/or don't care. Some IDEs make things worse by allowing you to filter out warnings and messages from their output, so that you can focus on compiler errors. That is good for good programmers (they will fix errors, compile again, and then study every single warning), but bad for those who are happy to have code that compiles at all, as they will run into 'do not show me warnings' mode.

npsimons 14y ago
The first reaction to an unfamiliar warning in any language should be to consult the manual (or Google it). In the case of VisualStudio at least, this is trivial (these days) due to the warning numbers you can paste into Google and usually get not just an explanation, but a way to fix it (usually via SO). Really, if a programmer can't fix warnings (and that includes taking the time to learn why they are there), what are you paying them for? My policy on projects I work on is to enable all warnings, treat them as errors, then only disable warnings after trying to fix them, researching them, and finally discussing them, and usually then only on a case by case basis (only occasionally do I eschew certain warnings altogether (such as -Waggregate-return for g++), and I leave them commented out with the reason they are disbled). (Edit: a quick tip for gcc, BTW: use -fdiagnostic-show-option for easier search of a warning, and the name of it in case you have to pragma it out).

marcosdumay 14y ago

I've just tried it. That code compiles without warnings by the default configuration of gcc version 4.4.5 (Debian 4.4.5-8) in my desktop (it's an up-to-date Debian Stable install). If the default settings of gcc included throuwing out warnings for every time a function is declared without parameters and missing the void, lots of people would complain, and loud. It's a very common construct.

kelnos 14y ago
Wow, that's crazy. I just tried it too (gcc 4.6.3). No warning options generate no warnings at all. -Wall only warns about the lack of return statement in main(). You only get the parameter-type default warning if you add -Wextra. Interestingly, adding -std=c99 oddly removes the warning about the missing return statement in main(). I can't find a way to warn about the empty param list in the prototype, but it's possible that it's just not considered "bad enough style" to warrant one. C++ is, of course, more strict. Try to compile that with g++, and you get several errors. The compiler needs to know how to mangle the symbol when it first encounters it, so you can't have "unspecified" parameter lists anywhere.