. Plab – Tirgul 3 Makefiles, Memory errors, Variables’ scope

Compilation & linkage.h read.h.c read.c.c main.c.c list.c.h list.h prog1 Linkage: g++ read.o main.o list.o –o prog1.o main.o.o list.o.o read.o Compilation: g++ -c read.c main.c list.c

Compilation & linkage.h read.h.c read.c.c main.c.c list.c.h list.h prog1.o main.o.o list.o.o read.o u If only one file is modified, will we have to recompile all over again? u No. The Makefile uses the dependencies graph

u Aim: Build only out-of-date files (use timestamps) u Makefile contains:  List of dependecies (no cycles)  “Recovery” scenario when any file is modified main.o: main.c list.h read.h g++ -c main.c u In words, if any of the files {main.c, list.h, read.h} was modified after main.o, the command “g++ -c main.c” will be performed Makefile Note, the tab here is essential!

Compilation & linkage.h read.h.c read.c.c main.c.c list.c.h list.h prog1.o main.o.o list.o.o read.o u If read.h is modified, what should be done? u We have to recreate only a subset of the files!

Compilation & linkage.h read.h.c read.c.c main.c.c list.c.h list.h prog1.o main.o.o list.o.o read.o Makefile example: prog1: read.o main.o list.o g++ main.o read.o list.o –o prog1 main.o: main.c read.h list.h g++ -c main.c read.o: read.c read.h g++ -c read.c list.o: list.c list.h g++ -c list.c Running make, e.g: make prog1 make main.o

Makefiles: macros u Macros are similar to variables  Upper case by convention  Example: OBJECTS = read.o list.o main.o prog1: ${OBJECTS} g++ ${OBJECTS} -o prog1

Makefiles: Explicit/implicit rules  We saw “explicit rules” so far, e.g: list.o: list.c list.h g++ -c list.c u Implicit rules (many kinds):  Example, creation by suffices. Create “.o” files from “.c” files.c.o: $*.c g++ -c –o $< $* - the match without the suffix (e.g. list) - file for which the match was made (e.g. list.o) $< - the matched dependency (e.g. list.c)

Makefiles: Explicit/implicit rules  One more example for implicit rule:.java.class: $*.java javac $< Result: For every “.java” file that was modified, a new “.class” file will be created. u When no explicit rule defined, an implicit rule will be used.  not always sufficient (e.g. doesn’t check.h files update)

. Some very common bugs (memory/pointers related)

bug 1 (1)struct Student { (2)int id; (3)char * name; (4)}; (5)Student * stud = (Student *) malloc( sizeof(Student) ); (6)stud->id = ; (7)stud->name = (char *) malloc(100*sizeof(char)); … (8)if (stud != NULL) { free(stud); } Memory leak!!! “name” is not free

bug 2 1) void myFunc() { 2) int * x = randomNum(); 3) int result = *x; //unexpected ! 4) *x = 17; //accessing unallocated space! 5) } 6) 7) int * randomNum() { 8) int j= srand( time(0) ); 9) return &j; 10) } u Never return a pointer of a stack-variable !

bug 3 1) void myFunc(char * input) { 2) char * name = NULL; 3) if (input != NULL ) { 4) name = (char*)malloc(MAX_SIZE); 5) strcpy(name,input); 6) } 7) … 8) free( name ); 9) } u Always use: if (output != NULL ) { free(output); }

bug 4 1) void myFunc(char * input) { 2) char * name; 3) if (input != NULL ) { 4) name = (char*)malloc(MAX_SIZE); 5) strcpy(output,input); 6) } 7) … 8) if ( name != NULL ) { 9) free( name ); 10) } 11) } u Always initialize pointers to NULL !

. Inter module variables’ scope

Static variables u Static variables in a function keep their value for the next call to the function  Allocated on the heap (1) void getUniqueID() { (2) static int id=0; (3) id++; (4) return id; (5) } (6) int main() { (7) int i = getUniqueID(); //i=1 (8) int j = getUniqueID(); //j=2 (9) }

Static variables, cont. u “static” variable on the global scope  Available only in the current module u “extern” variable  Defined outside the module file2.c extern int y; //y from file1.c extern int x; //x defined elsewhere int myFunc() { int y; //error … } file1.c int y; static int x; int myFunc() { int x; //error … }