C Programming Survival Guide for COMP 206

Damien Levac (dlevac@cs.mcgill.ca)

October 20, 2016

Motivation

C is often referred to as portable assembly. It is one of the simplest language you will learn in Computer Science and yet
I find students struggling as if it was the most complicated entity they ever encountered. This motivated me to write this
little guide that will make COMP 206 your easiest course this semester.
You can suggest improuvements to this guide by sending me an email.

Optional: Coding Style

Most people cant write consistency and elegant code: I do not personally understand why. If you want to fix this, why
not use the coding style of the most successful piece of C software in the history of Computer Science?
https://www.kernel.org/doc/Documentation/CodingStyle

Tools

3.1

Compilers

You already learned that a C compiler (here gcc) compiles your C code into an executable. Truth is that it can do so
much more for you. From now on, you will be compiling your program as follow:
g c c o a . out s t d=c11 ggdb Wall Wextra p e d a n t i c . c
std=c11 specify to use the latest C programming language standard that was released in 2011. It is the least
important flag but it is good you know what you are programming in.
ggdb compiles your code with extra debugging information embedded into the executable. This will become handy
later.
Wall Wextra display all warnings and extra warnings: most of the bugs in your code, at your level, are trivial to
the compiler. There should be no warning left before you even start debugging the behaviour of your program.
pedantic instruct the compiler to only accept code that strictly adhere to the C standard, i.e. disallow compiler
extensions. This make sure that you are writing C code that is portable and that your professor (or TA) will have
no problem compiling.
Obviously you replace o a.out and .c by the name you want for the executable and the text files you want to compile
respectively.
Also note that gcc is just one compiler, clang is another compiler that uses the exact same syntax. Thus, if an error or
a warning does not make sense on one compiler, you can try compiling it with the second compiler and hope for a more
enlighting output.

3.2

Memory Checker

The name memory checker might be misleading for the tool I am about to show you as it does so much more than just
checking your memory usage: valgrind.
Basically, valgrind will run the program for you and warn you about any anomaly it encounters: John Carmack
programmed on UNIX for this very tool.
#i n c l u d e <s t d i o . h>
int
main ( void )
{
int a ;
i f ( a > 0) {
p r i n t f ( Whether t h i s t e x t i s p r i n t e d o r not i s a mystery . ) ;
}
return 0 ;
}
This code example would result in this output from valgrind ./a.out:
==5027==
==5027==
==5027==
==5027==
==5027==
==5027==
==5027==
==5027==
==5027==
==5027==
==5027==
==5027==
==5027==
==5027==
==5027==
==5027==
==5027==
==5027==

Memcheck , a memory e r r o r d e t e c t o r
Copyright (C) 2002 2015 , and GNU GPL d , by J u l i a n Seward e t a l .
Using Valg rind 3 . 1 1 . 0 and LibVEX ; r e r u n with h f o r c o p y r i g h t i n f o
Command : . / a . out
C o n d i t i o n a l jump o r move depends on u n i n i t i a l i s e d v a l u e ( s )
a t 0 x400532 : main ( example . c : 8 )

HEAP SUMMARY:
in use at e x i t : 0 bytes in 0 blocks
t o t a l heap u s a g e : 0 a l l o c s , 0 f r e e s , 0 b y t e s a l l o c a t e d
A l l heap b l o c k s were f r e e d no l e a k s a r e p o s s i b l e
For c o u n t s o f d e t e c t e d and s u p p r e s s e d e r r o r s , r e r u n with : v
Use t r a c k o r i g i n s=y e s t o s e e where u n i n i t i a l i s e d v a l u e s come from
ERROR SUMMARY: 1 e r r o r s from 1 c o n t e x t s ( s u p p r e s s e d : 0 from 0 )

Here valgrind see that the conditional (if-statement) depends on a value that was not initialized (namely a) and gives
you the filename (example.c) and the line number (8) where it happens. Note that it is able to tell the line number thanks
to the ggdb flag from earlier.
This tool is also useful to determine the exact line where a segmentation fault occur, if you forget to call free after a
malloc, if you access memory that does not belong to you and so much more.

Closing Note

The above is the minimum you should know if you just want to pass COMP 206 without hassle. If you wish to be more
proefficient with this nice IDE that is UNIX, you may want to look into the following.
A proper text editor (e.g. vim or emacs).
A terminal multiplexor (e.g. screen or tmux).
A debugger (e.g. gdb).
A build automation tool (e.g. make).