Well I spent an interessting night, still havn’t solved the issue of whats wrong but I did accomlish a few things. Better code checking with gcc How to use lint How to use the GNU Debugger Personally I think that graphical front ends can have some very great advantages. But one should be able to use the basic tools by hand when/if necessary. As being able to live in a shell (no gui enviroment) is a part of my studies. So Being able to use a debugger on the CLI is important to me. Oh well each in turn. Most IDE’s provide some sort of user interface to wrap around the make and debuging tools. The basic idea that most compilers (so I’ve heard) follow including the GNU Compiler Collection gcc/g++ (gnu c/c++ compiler) use. Are as follows. gcc source.file -o outfile Now we don’t need the -o outfile if we like for example to compile our source.file into an execuitable named a.out in this case ! With the -o option we can choose a name for the execuitable. So ‘gcc rf.c -o rf’ would create an executible named ‘rf’ instead of ‘a.out’ from our rf.c source file. Is this any harder then Build->Compile in an IDE /w a mouse? Not really in my humble opinoin. Especially if you can sider that CLI access is embedded in many editors and many editors work in the CLI. Lets turn on some simple warnings gcc source.file -Wall -o outfile Now while one might argue any code that compiles and works is good enough. But what if it doesn’t work as exspected or it’s not very good? The -Wall option will at least give us a stronger warnings and errors about bad practices. Since -Wall turns on a bunch of warnings I’ll walk through some of them at the end. I personally have used -Wall since I found out there was an all switch (Thank you FreeBSD KNF Style manual!). And when it trips a warning message it usually reminds me I’m doing some thing wrong or I need to go correct a magic typomatical error. I noticed a few other niffty things in the OpenBSD KNF style guide. gcc -Wall -W -Wpointer-arith -Wbad-function-cast source.file -o outfile Gives us plenty of useless-to-semi-useful-to-useful information at times. Theres even more options. Since this is a lot more to type and I’m to lazy to whip up a little Makefile for all my stuff. I made a shell alias for it. I think its worth while to explore the available warning options and sort them as one needs. Note to self, work on some Makefile templets. Another intereing tool I always wanted to toy with, is lint. lint is a code checker for trying to detect features in C sources that are likely to be bugs, non-portable, or wasteful, e.t.c. The lint program h as a good enouhg manual which documents its command line switches but the basic useage is. lint source.c So far I like the -cehuz options most often and have an alias for it. And the -s and -p options from time to time have use hehehe. One thing I found odd about lint, is that it complaned about my // comments. rf.c(5): warning: ANSI C does not support // comments [312] Normally I use only /**/ comments and occasionally a few // in C++. Or I’ll mix /**/ and // comments if I’m leaving my self comments of diffrent types in a non-source file. Like /* Change done to something */ What I changed // Note for later for a meeting about it When I’m writing up files for things as I do’em. In this partuclar file how ever, since rf.c has been floating between systems a bit and editors I placed a pair of mode lines in it to set some options for my editors.
/*
* rf read file to standard out
*/
// vim: set noexpandtab ts=8 sw=4 ai :
// vi: set ai nu sw=4 :
Basically turn on line numbering in Vi and make sure my indentation settings are consistant, then turn on auto-indent in case I want it. (I don’t often use it). I remember, why I started using strictly /* Comments */ when I had always used // comments before. Was because I was told that some (older) compilers had problems with the newer // Comments. To use the GNU Debugger gdb to debug a program, first we need to enable the debugging symbols in GCC. We can do this by appending a -ggdb option some where in our compilation. gcc -Wall source.c -o outfile -ggdb Then we can run gdb outfile to start the debugger. At first when I tried looking at the debugger ages ago I didn’t have much luck with it. But after reading the manual like I usually do _before_ toying with CLI software it makes much more sense. You can get a topic list by typing help and more specific help like help breakpoints With GDB we can step through the program line by line, set break points at lines and/or functions. Examine data since as what value does variable foo have ? Run backtraces, look at the stack, set the command line arguments and all kinds of stuff. Really GDB deserves its own attention to the subject. Its long been my practice to save and pump code through GCC every few minutes or routines just to see if I missed any syntax errors I may have made. You don’t want to know how many times I’ve been preplexed just because I used a comma instead of a period or a period instead of a comma. And after hours infront of an editor couldn’t see the difference in my font lol – yes I am looking for a better fixed-width font ^_^ Now with lint and the various options of GCC I can do more for less 🙂 Since trying todo ANY THING during day light is pointless in this family. And trust me, when your the kind that inhales good manuals. And it takes you 30 minutes just to get through the first paragraph of a manual on PHP Syntax you know you have a fucking problem. So si nce I can’t code during the day. I have to do it late at night and I can’t do shit for long. So like 0735 in the morning these tools do kind of help me correct errors. From man 1 gcc Warnings are diagnostic messages that report constructions which are not inherently erroneous but which are risky or suggest there may have been an error.
The -Wall option I listed turns on all this according to the manual Warn whenever a declaration does not specify a type. Warn whenever a function is used before being declared. Warn if the main function is declared or defined with a suspicious type. Warn whenever a function is defined with a return-type that defaults to int. Also warn about any return statement with no return-value in a function whose return-type is not void. Warn whenever a local variable is unused aside from its declaration, whenever a function is declared static but never defined, and whenever a statement computes a result that is explicitly not used. Warn whenever a switch statement has an index of enumeral type and lacks a case for one or more of the named codes of that enumeration. (The presence of a default label prevents this warning.) case labels outside the enumeration range also provoke warnings when this option is used. Warn whenever a comment-start sequence `/*’ appears in a comment. Warn if any trigraphs are encountered (assuming they are enabled). Check calls to printf and scanf, etc., to make sure that the arguments supplied have types appropriate to the format string specified. Warn if an array subscript has type char. This is a common cause of error, as programmers often forget that this type is signed on some machines. Some optimization related stuff. Warn if parentheses are omitted in certain contexts. When using templates in a C++ program, warn if debugging is not yet fully available (C++ only). From man 1 gcc: The remaining `-W…’ options are not implied by `-Wall’ because they warn about constructions that we consider reasonable to use, on occa sion, in clean programs.
And here they are stright from the fine manual.
-Wtraditional
Warn about certain constructs that behave differently in tradi-
tional and ANSI C.
o Macro arguments occurring within string constants in the macro
body. These would substitute the argument in traditional C, but
are part of the constant in ANSI C.
o A function declared external in one block and then used after
the end of the block.
o A switch statement has an operand of type long.
-Wshadow
Warn whenever a local variable shadows another local variable.
-Wid-clash-len
Warn whenever two distinct identifiers match in the first len
characters. This may help you prepare a program that will com-
pile with certain obsolete, brain-damaged compilers.
-Wpointer-arith
Warn about anything that depends on the "size of" a function
type or of void. GNU C assigns these types a size of 1, for
convenience in calculations with void * pointers and pointers to
functions.
-Wcast-qual
Warn whenever a pointer is cast so as to remove a type qualifier
from the target type. For example, warn if a const char * is
cast to an ordinary char *.
-Wcast-align
Warn whenever a pointer is cast such that the required alignment
of the target is increased. For example, warn if a char * is
cast to an int * on machines where integers can only be accessed
at two- or four-byte boundaries.
-Wwrite-strings
Give string constants the type const char[length] so that copy-
ing the address of one into a non-const char * pointer will get
a warning. These warnings will help you find at compile time
code that can try to write into a string constant, but only if
you have been very careful about using const in declarations and
prototypes. Otherwise, it will just be a nuisance; this is why
we did not make `-Wall' request these warnings.
-Wconversion
Warn if a prototype causes a type conversion that is different
from what would happen to the same argument in the absence of a
prototype. This includes conversions of fixed point to floating
and vice versa, and conversions changing the width or signedness
of a fixed point argument except when the same as the default
promotion.
-Waggregate-return
Warn if any functions that return structures or unions are de-
fined or called. (In languages where you can return an array,
this also elicits a warning.)
-Wstrict-prototypes
Warn if a function is declared or defined without specifying the
argument types. (An old-style function definition is permitted
without a warning if preceded by a declaration which specifies
the argument types.)
-Wmissing-prototypes
Warn if a global function is defined without a previous proto-
type declaration. This warning is issued even if the definition
itself provides a prototype. The aim is to detect global func-
tions that fail to be declared in header files.
-Wmissing-declarations
Warn if a global function is defined without a previous declara-
tion. Do so even if the definition itself provides a prototype.
Use this option to detect global functions that are not declared
in header files.
-Wredundant-decls
Warn if anything is declared more than once in the same scope,
even in cases where multiple declaration is valid and changes
nothing.
-Wnested-externs
Warn if an extern declaration is encountered within a function.
-Wenum-clash
Warn about conversion between different enumeration types (C++
only).
-Wlong-long
Warn if long long type is used. This is default. To inhibit
the warning messages, use flag `-Wno-long-long'. Flags
`-W-long-long' and `-Wno-long-long' are taken into account only
when flag `-pedantic' is used.
-Woverloaded-virtual
(C++ only.) In a derived class, the definitions of virtual
functions must match the type signature of a virtual function
declared in the base class. Use this option to request warnings
when a derived class declares a function that may be an erro-
neous attempt to define a virtual function: that is, warn when a
function with the same name as a virtual function in the base
class, but with a type signature that doesn't match any virtual
functions from the base class.
-Winline
Warn if a function can not be inlined, and either it was de-
clared as inline, or else the -finline-functions option was giv-
en.
-Werror
Treat warnings as errors; abort compilation after any warning.