Answers for gcc Lab

get_input
The error occurs on line 18. If you said that the error was on line 8 where the variable in_str is created as a NULL pointer that is also correct. This is a copy of the gdb error message and stack trace (acquired by using the backtrace [bt] command).
```
Program received signal SIGSEGV, Segmentation fault.
0xef76d1d0 in string ()
(gdb) bt
#0  0xef76d1d0 in string ()
#1  0xef76c5a8 in __doscan_u ()
#2  0xef76bef8 in _doscan ()
#3  0xef7705b0 in scanf ()
#4  0x107c8 in main (argc=2, argv=0xeffff6d4) at get_input.c:18
(gdb) 
```
A correct way to compile this is
gcc -g get_input.c -o get_input
first_try
To compile the program corrctly
gcc -g -DRUN=4 -DVIEW first.c -o first_try
The '-g' is necessary for information for debugging. In this case the '-DVIEW' is necessary for error messages and the '-DRUN=4' is necessary so that it compiles at all. Would we ever actually used the RUN=4 ? Possibly. You may have code that needs to be portable. In that case you may be forced to use several different compilers. This is a way to keep the user from having to modify the code. The user just has to be told the proper way to compile it for a given machine and compiler.
how
You have to tell the compiler to include the math library.
gcc how.c -o how -lm
The -lm tells the compiler (linker actually) to search its set of paths for a library named "libm.a". What should you have done if you had not read the line in the lecture discussing this? Well the compiler gave this error
```
Undefined                       first referenced
 symbol                             in file
sqrt                                /var/tmp/cca001wW1.o
ld: fatal: Symbol referencing errors. No output written to a.out
```
which is pretty esoteric. But what do you know? You know that "sqrt" is the problem. So when you look at the file how.c you see that "sqrt" is a function. Now I told you that the man pages would give information pertinent to functions, especially any additional information you might need to compile a program using it. So lets do
```
UNIX> man sqrt
```
and we get a page that has this in it
```
SYNOPSIS
     cc [ flag ... ] file ...  -lm [ library ... ]

     #include <math.h>

     double sqrt(double x);
```
The line immediately under the SYNOPSIS is a sample compiler command. Note the "-lm". Items in brackets, [], are optional, the rest are required. This page also says you need to include the math.h header file. And if you look at the source code it is there. Had you left out that header you would have gotten an additional error
```
how.c: In function `main':
how.c:23: warning: type mismatch in implicit declaration for built-in
function `sqrt'.
```
sample
Compile the program for testing with purify.
purify gcc -g sample.c -o sample
Output without purify
```
J+Pt?'xS8CCz^vev'*$xRpFR,9IDa`T-'KQOm%#D#Eo+&X-U+(|RTrw:bo6F: first
?Ãp$Þßð: duplicate of first
```
Output with purify
```
J+Pt?'xS8CCz^vev'*$xRpFR,9IDa`T-'KQOm%#D#Eo+&X-U+(|RTrw:bo6Fÿð: first
J+Pt?'xS8CCz^vev'*$xRpFR,9IDa`T-'KQOm%#D#Eo+&X-U+(|RTrw:bo6Fÿð: duplicate of first
```
Errors:
- ABW- Array Bounds Write - occurs on line 25 and line 32.
- UMR- Uninitialized Memory Read - occurs on line 29 and line 37
The reason the ouputs are different is purify "traps" all those nasty ABW errors and does not let them occur. The point is be aware that when you use purify, the program's results can appear to be correct (or incorrect) even if the program is behaving badly.
what_not and why_not i
Comparisons:
Note: These results will differ wildly from any you ran or may run in the future. But there will be approximately the same number of functions called and the times should show the same relative speeds even though the numbers themselves won't match at all.
- what_not - uses 49 functions that quantify can access. Total time for input 'small' on a hydra machine is .061 seconds, 97% of that in system calls. Spent 73% of its time reading, 23% writing. Total time for input 'large' on a hydra machine is 6.669 seconds, 98.5% in system calls. 54% of time reading, 45% of time writing.
- why_not - uses 35 functions that quantify can access. Total time for input 'small' on a hydra machine is .013 seconds, 94% of time spent in system calls. 91% of time spent writing, 6% of time in main and less than 1% of time reading. Total time for input 'large' on a hydra machine is 6.228 seconds, 97% in function calls. 97% of time spent writing, 2.5% of time in main and .2% of time reading.
Which sould I choose? Well, why_not runs faster for both inputs. It uses fewer functions thereby reducing function call overhead as indicated by the fact that the percentage of time spent in system calls is always lower than for what_not. Why_not doesn't spend any significant time reading. If I only have to worry about time spent writing, I can probably make that faster too. So by choosing why_not I get code that is simpler, runs faster and could probably be easily improved.