Saturday, February 3, 2007

late night

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.

No comments:

Post a Comment