Try passing at least the -Wall and -Wextra flags.

For learning, you could also add -ansi, as it will make your compiler be stricter about standards.

And probably -Werror (all warnings become errors, breaking compilation).

Fun post. Now I know why everyone was raving about the clang error-messages:

    echo "void main() {}" > main.c


    gcc -Wall -Werror --std=c99 main.c 
    main.c:1:6: error: return type of ‘main’ is not ‘int’ [-Werror=main]
    cc1: all warnings being treated as errors


    clang -Wall -Werror --std=c99 main.c 
    main.c:1:1: error: 'main' must return 'int'
    void main() {}
    ^
    1 error generated.

    (not showing clangs pretty colours)

Nice suggestion. Although I can't seem where one would have to look for those "pretty colours" you mentioned, I certainly can't see any of them on my Mac terminal...

Can't help you there -- but I don't think I've set any exotic terminal variables or anything like that, and I get this:

http://i.imgur.com/BjWj7h6.png

FWIW, I have:

    COLORTERM=gnome-terminal
    TERM=screen

and Debian takes care of my termcap etc, afaik.

Think its his TERM env most likely being straight xterm (no color ansi escapes in the termcap iirc).

http://i.imgur.com/0Hzze9G.png

Thats me on osx running tmux with TERM=xterm-256color.

instead of -ansi, i'd argue that -std=c99 (or -std=c11) would be more appropriate. also note the -pedantic flag.

"-Weverything" if the code is compiling perfectly, but you're just bored. If you're not a complete masochist try turning off some of the sillier ones (-Wno-padded -Wno-unused-parameter -Wno-conversion)

The Mac OS X C compiler is clang, no need to install anything extra.

C is insecure by design and IT is still paying for its widespread, when used by developers that don't use the best practices for secure C coding.

So when learning how to use it, the best way is to learn those best practices from day one.

Absolutely, but my way of going about this would be to first show _why_ something is a best practice, rather than forcing people to take it at face value.

The problem is that people are allowed to take the easy route, they will never write secure code.

Writing secure code is always harder than not, and developers love to take shortcuts.

For example, many of the IO functions like gets() are no longer valid in C11 exactly because how unsafe they are.

A more conservative rule would be not to use C where security is a concern, unless you know what you're doing.

When you're writing the kind of software that's an invitation to hackers, like a web application, you should favor a language like PHP or Ruby, which takes things like buffer overflows out of the equation, and even then, you should know what you're doing.

> A more conservative rule would be not to use C where security is a concern, unless you know what you're doing.

Which if you follow my posts, you will see that I defend C and C++ should be replaced by safer systems programming languages, that exist since Modula-2 days.

Having said this, C and C++ are still used everywhere and will outlive most of us.

So when using them, for whatever reasons, at least one should take care to use the best practices regarding how to write secure and safe code in those languages.

Is it installed out of the box? I think you might need Xcode (or at least the command line tools). These instructions may help: http://railsapps.github.io/xcode-command-line-tools.html

> Is it installed out of the box?

No, Joe average user does not compile code.