Hacker News Reader

Comment by TeMPOraL | Hacker News Reader

Pro tip: when you develop with gcc, don't settle for anything less than

    gcc -ansi -pedantic -Wall

At university I often had people coming to me and asking, "my program compiles correctly, but it keeps crashing / doing weird things; what did I do wrong?". I always said, "add '-ansi -pedantic -Wall' to the compile flags and come back to me when you cleared that wall of warnings down to nothing". Every single time the problem was directly or indirectly caused by the things that were in the warning messages.

It's a shame that the default choice of GCC flags make this compiler pretty much useless for work.

The warnings are there to help you. You can choose to ignore them and that's fine, as long as you do it deliberately and with a damn good reason, not because you don't even know they're there.

View on HN

You can go further and specify a particular standard, plus extra warnings not included in -Wall:

    gcc -std=c99 -Wall -Wextra -Werror

I'm not sure if -pedantic is still beneficial in that case. The gcc documentation had a list of every warning category, and which parameters enable each warning. This SO question was also interesting: http://stackoverflow.com/questions/11714827/how-to-turn-on-l...

-std=cNN specifies the base language standard. Much existing code depends on GCC extensions to that standard (for better or for worse), so it is often necessary to use -std=gnuNN instead (specifying base language dialect + extensions).

clang has -Weverything, which means, well, warn about everything.

Also —analyze to run the static analyzer: http://clang-analyzer.llvm.org

One of my professors in college wouldn't accept code that didn't compile with the invocation.

"Your compiler is trying to help you. Listen to it."

A tiny comparison: -Wall -pedantic gives me:

  warning: C++ style comments are not allowed in ISO C90
  warning: ISO C90 forbids mixed declarations and code

-Wall -Wextra gives me:

   warning: unused parameter ‘type’

For me, -Wextra is much more useful for finding messy code.

Use both of them. The last warning is about messy code, but the first two will help you keep the code portable.

Even when you do have a good reason to ignore them, you should still either disable that specific type of warning or, better yet, disable that specific warning for that specific spot in code using gcc's diagnostic pragmas [1].

[1] http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Diagnostic-Pragm...

I agree. This way you signal to other programmers reading the code that you were in fact aware of the warning and made a conscious decision to disregard it.

-ansi and -pedantic often produce a lot of useless output unless your goal is to really target C89.

-Wall is enough to catch most relevant things, throw in -Wextra if you want overkill, not -ansi -pedantic.

> It's a shame that the default choice of GCC flags make this compiler pretty much useless for work.

I disagree (not "strongly" because your clarification in the next paragraph). That's only true if you don't know what are you doing.

That said, I am a big fan of gcc's -Wall since the late 90s, and I can tell you gcc has improved a lot since then.

I think even the most skilled programmer can benefit from making their code pass -Wall completely, even if just for the sake of sharing with other developers (but we all make mistakes and it'll likely catch some of those too!).

There's a reason that for quite a number of these warnings, Go has either designed the causes out of the language (no implicit casting, only manual conversions), or promoted them to compiler errors (unused variables and imports).

Note: -ansi is equivalent to -std=c90 (in C mode). If you want C99 or C11 support, use -std=c99 or -std=c11.

-ansi is one of the most poorly named compiler flags of all time; C11 is the current ANSI C standard, but compiling with -ansi in GCC specifies a language dialect that’s a quarter of a century old(!)

It was named when "ANSI or not ANSI?" was the interesting question, and stuck around for compatibility. It should be kept and its semantics should not be changed, but it should be called out as deprecated. At least the gcc man page does say "In C mode, this is equivalent to -std=c90. In C++ mode, it is equivalent to -std=c++98."

True, but colloquially, when people say "ansi C" they almost always mean C89.

True, but when people say "ansi C", then Clinton is almost always president.

(I say this because these days, I hear "C89" or "C90", "C99", or "C11". People who say "ANSI" get asked for clarification.)

That is a very developer mindset.

Remember, many more of us use the compiler to build packages in the wild, we need it to be fairly permissive to hope to get things to build.

Yes, but if more developers used these flags the world would be a better place. Whenever I have the time, I build with these flags and report bugs back to the upstream developers. Then I drop the flags and move on with my life :)

That is genius! This would be a great way to get university kids to contribute to the OSS movement.

Furthermore, I wish I had known earlier how much I could contribute to the open-source community by simply downloading a product, walking through their documentation, and submitting corrections, and little usability improvements to both the interfaces and documentation. It's an easy way to start learning your way around the code and internal architecture.

This seems to deserve mention here: https://openhatch.org

It may be a developer mindset sure, but look at the post you are commenting on... It's a series of posters made for developers to influence their choice of memory handling functions. Context matters quite a bit.

Ansi and pedantic are solely about standards compliance; that's often not what I want. It means my code might not be portable to other compilers, but a lot of other compilers implement much or all of GCC's extensions. If the extensions help you write better, safer code faster, use them! I whole-heartedly agree about -Wall, and would add -Werror and -Wextra, and would recommend skimming the list for other things that might be appropriate but aren't enabled by default.

If you have clang available, the -fsanitize flag is also incredibly helpful for runtime analysis.

Reply on news.ycombinator.com