P The basic problem the Routine Analyzer is trying to solve is how to assimilate aJ large software product that may consist of dozens, even hundreds of sourceO files, and hundreds of thousands of lines of source code. Where to begin? Where O to go? How to identify the relationship between routines, such that an engineer G can enhance or correct the product without introducing new problems?
O The Routine Analyzer is just one of the tools an engineer can use in working on P a large software project. Several other tools provide similar capabilities, suchG as Source Code Analyzer under VMS, and cscope under Unix. Tools such as M cross-reference utilities and compiler and linker listings provide additional H information. Each tool has its own benefits and limitations. The RoutineD Analyzer is intended to supplement other tools, not replace them.
9 The Routine Analyzer runs under VMS, Unix, and MS-DOS.
Reports
M The Routine Analyzer produces the following reports from a software product's source code:
How It Works
L The analysis process is very analogous to a software build, in which a buildO utility identifies the source file to compile, compiles them, and links them to O form the product image. The analyzer reads a list of source file locations from M a product definition file, analyzes them, and produces the reports. It I works in two phases, an analysis phase, and a report generation phase.
P During the analysis phase, the analyzer identifies the source language of a fileP based on the file type or extension, matching the type to known file types or toL special types listed in a language definition file. It then selects aO parser for that language and parses the contents of the source file, similar to M the way a compiler parses a source file (note, however, that the parsers used L here are much simpler than true compiler front ends, and ignore many detailsK that are important to a compiler). The parser notes each routine definition P (i.e. the actual routine contents) and each call to a routine that it encountersP in the source code, building cross-reference information and maintaining various counters.
P When it has parsed the contents of all the source files, the analyzer enters theM report generation phase. First, it formats the lists of files and routines it K has built. Then it trims duplicate references and identifies recursion, and N formats the cross references and call trees. Finally, it formats the annotated source listings.
E The analyzer supports mixed-language programming since it selects the O appropriate parser on a file-by-file basis (though it does not recognized mixed L languages within a single file). It permits multiple definitions of the sameG routine, for example to provide alternate implementations for different O operating systems. It can also be used on partial code sets, where a compile or ' link might fail due to missing code.
Supported Languages
N Currently, the analyzer supports three source languages: C, BLISS, and text. CK and BLISS are the primary high-level languages used in current and existing P Digital products. The text language is actually just a dummy parser that acceptsH all input without looking for routines, and can be used to capture filesK containing text or unsupported source languages in the analysis reports.
I Future language support under consideration is for C++, PERL, and several N assembly languages. Assembly languages present a special challenge in that theN bounds of a routine definition are not as clear as in high-level languages.
Report Formats
M Currently, the analyzer produces reports in two formats: SDML, and HTML. SDML N (Standard Digital Markup Language) is the input format for VAX Document, whichH can produce ASCII text, PostScript, or Bookreader output. This format isM especially suited to hardcopy documentation when producing PostScript output. H HTML (Hyper Text Markup Language) is the input format for World-Wide WebM browsers such as Mosaic. This format is especially suited to online browsing, P since it includes hypertext links between related items in the reports for quick navigation.
O SDML reports are created in a small set of files that can be used standalone or N included in other documents, either together or individually. HTML reports areF created in a somewhat larger set of files that are optimized for quick> browsing, and are intended to be used as an integrated set.
O Future report formats under consideration are for ASCII text, Windows Rich Text , Format (RTF), Windows Help, and VMS Help.
k " ( The Product Definition File
M The Product Definition File is a required text listing the source files to beiO analyzed. The first line of the file is the product identification line. It can L contain any text, which will be used to identify the product in the reports.K Each remaining line contains one source file pathname. The pathnames may be I complete, absolute pathnames, or they may be relative pathnames. RelativeiL pathnames are relative to the current working directory when the analyzer isO run. Wildcards are not permitted, and Unix shell abbreviations, such as "~" fortO the user's home directory, are not recognized. Remember that Unix filenames areo: case-sensitive, while VMS and MS-DOS filenames are not.
N For example, the following are product definition files for Unix and VMS. TheyM are for a hypothetical mail utility that uses an X Windows interface. In both>K cases, the source files are in several subdirectories under a master source=2 directory, from which the analyzer will be run:
E+ Unix: VMS:/ 2 % cat myxmail.prd $ type myxmail.prd5 X Windows Mail System X Windows Mail Systeme1 send/finduser.c [.send]finduser.cr1 send/sendmail.c [.send]sendmail.c=/ rcv/getmail.c [.rcv]getmail.co0 rcv/showmail.c [.rcv]showmail.c1 file/savemail.c [.file]savemail.ca3 file/importmail.c [.file]importmail.cs1 file/movemail.c [.file]movemail.cr2 gui/mainwindow.c [.gui]mainwindow.c2 gui/sendwindow.c [.gui]sendwindow.c1 gui/rcvwindow.c [.gui]rcvwindow.c# t)
o L For example, the following is a language definition file valid for both UnixN and VMS. It shows the default file types for the supported languages, plus oneM definition for an unsupported assembly language. However, note that it is notEN necessary to include the default language definitions, and if all files listedJ in the product definition file are types known to the analyzer, a language$ definition file is not necessary.
r % cat myxmail.lngB ! The following are the default file type/language definitions. !' c=c ! .c file type is C code>' h=c ! .h file type is C code - bli=bliss ! .bli file type is BLISS codee- req=bliss ! .req file type is BLISS code - r32=bliss ! .r32 file type is BLISS codes- dat=text ! .dat file type is plain texts- txt=text ! .txt file type is plain texte !4 ! The following is a custom C language file type. !) myc=c ! .myc file type is C coden !C ! The following tell the analyzer to treat assembly language andiA ! options files as plain text so that they will be included iniD ! the annotated source output, even though the analyzer is unable ! to parse them.e !6 asm=text ! Treat assembly language as plain text1 opt=text ! Treat options file as plain textfi
s Z For example, the following are options files for Unix and VMS. Note that the option switch9 character for Unix and MS-DOS is "-", and for VMS is "/".u
+ Unix: VMS:t 2 % cat myxmail.opt $ type myxmail.opt, -format=html /format=html@ -outprefix=/devdocs/xmail_ /outprefix=dev$docs:xmail_ 1 -lang=myxmail.lng /lang=myxmail.lngi" $
r. ranalyzer product_definition_file [options]A where product_definition_file is the product definition file, and 1 [options] are any desired command options (see
L All relative file pathnames in the product definition file are assumed to beM relative to the current directory from which the analyzer is run. All reportstP are created in the current directory, unless the "outprefix" option is used withM a pathname. The reports use fixed filenames, as shown in the following table;iK the "outprefix" option may be used to specify an additional prefix to thesea names:
e
y% Report File name Continuation filesi: ---------------------- -------------- ------------------ Source file list: filesi( Routines by file list: byfile byfxxxxx Defined routines: defineda External routines: undefind. Cross references: xref xrfxxxxx Annotated source code: srcxxxxxM where xxxxx is a decimal sequence number. The file type is ".sdml" or ".html"dK for Unix and VMS, and ".sdm" or ".htm" for MS-DOS. Annotated source code isdN reported one report file per source file. Continuation files are used only forP HTML output. These are used to split large reports into smaller, more manageableL HTML files to ensure responsiveness while browsing (see the "htmlbyfile" andC "htmlxref" options for changing the size of continuation files).
a I Progress messages are written to standard output. The "brief" or "silent"lM options may be used to reduce the volume of messages. The "log" option may be used to redirect messages. M For example, the following commands run the analyzer under Unix and VMS. theylL will create HTML format reports, in the directory /devdoc (Unix) or dev$doc:K (VMS); the additional prefix "myxmail_" will be prepended to the fixed file"P names. The analyzer program file is assumed to be /tools/bin/ranalyzer (Unix) or sys$tools:ranalyzer.exe (VMS).
r Unix:a # % setenv PATH ${PATH}:/tools/binfC % ranalyzer myxmail.prd -format=html -outprefix=/devdoc/myxmail_a . . . % ls /devdoc/myxmail_*r@ /devdoc/myxmail_byfile.html /devdoc/myxmail_src00006.html@ /devdoc/myxmail_defined.html /devdoc/myxmail_src00007.html@ /devdoc/myxmail_files.html /devdoc/myxmail_src00008.html@ /devdoc/myxmail_src00001.html /devdoc/myxmail_src00009.html@ /devdoc/myxmail_src00002.html /devdoc/myxmail_src00010.html@ /devdoc/myxmail_src00003.html /devdoc/myxmail_undefind.html< /devdoc/myxmail_src00004.html /devdoc/myxmail_xref.html /devdoc/myxmail_src00005.html VMS: , $ ranalyzer :== $ sys$tools:ranalyzer.exeC $ ranalyzer myxmail.prd /format=html /outprefix=dev$doc:myxmail_p .
. . $ dir dev$doc:myxmail_* Directory DEV$DSK:[DOC] 3 MYXMAIL_BYFILE.HTML;1 MYXMAIL_DEFINED.HTML;1y4 MYXMAIL_FILES.HTML;1 MYXMAIL_SRC00001.HTML;14 MYXMAIL_SRC00002.HTML;1 MYXMAIL_SRC00003.HTML;14 MYXMAIL_SRC00004.HTML;1 MYXMAIL_SRC00005.HTML;14 MYXMAIL_SRC00006.HTML;1 MYXMAIL_SRC00007.HTML;14 MYXMAIL_SRC00008.HTML;1 MYXMAIL_SRC00009.HTML;14 MYXMAIL_SRC00010.HTML;1 MYXMAIL_UNDEFIND.HTML;1 MYXMAIL_XREF.HTML;1 Total of 15 files.e # t% p P The best way to use the reports is to start with either the alphabetical list ofN source files or the alphabetical list of defined routines. In HTML format, theM list of source files acts as the home page for the report set. From these you P can go to the source code or the cross reference information, rapidly traversing the code paths of interest.
P The reports have the same general appearance regardless of actual output format,L using the formatting directives available. For instance, SDML has formattingM directives that directly support multi-column tables. HTML does not; instead,bO tables are formed from pre-formatted text. All the samples below are taken fromnL HTML-formatted reports, based on analysis of the analyzer's own source code;= hypertext links are not shown, but are described in the text. e& Source Files Alphabetical
N The alphabetical list of source files report shows high level statistics about? the source code. The following is a sample source file list:
wO ------------------------------------------------------------------------------- N +- Link to annotated source code for the file. /L / +- Link to routines byK Source Files / / file for the file.i5 v vaO ===============================================================================dK Com- State- Rou- Avg # O File Lines mented ment tines Length Len CallsaO -------------------------------------------------------------------------------! The columns in this table are:
K
O These values can be used to gauge the overall size and complexity of the sourcepP code, as well as hint at its maintainability. For instance, does the code have aM high proportion of comments, suggesting good internal documentation, or a low M (or non-existent) proportion? Is the average routine length large, suggestingzA very large, complex routines, or is it small, suggesting compact,hN easily-comprehended routines? The relative complexity of different portions ofL code may be gauged by comparing the values for different files. Note that inN interpreting these values, different people will judge them differently, based& on their own experience and skills.- File: The name of the source file as it appears in the K product definition file (see The Product L Definition File for a description). The table entries are sorted by thisK column. The sort includes any pathname information in the file name. If theaP files are spread over multiple directories, all the files in each directory will be grouped together. L
- Lines: The total number of lines in the file, includingG blank lines. In the HTML format, this column is a hypertext link to them# annotated source code for the file.l M
- Commented: The total number of lines that contain source]H language comments. These lines may consist of only comment text, or both( comments and source language statements. M
- Statement: The total number of lines that contain sourcemH language statements. These lines may consist of only statements, or bothP statements and comments. Since lines containing both will be counted in both theL Commented and Statement columns, the sum of these two columns may exceed the Lines column.o P
- Routines: The total number of routines defined in the file.O A routine definition means the body of a routine, not just a declaration of the O routine interface. Macros are treated as routines, since they are an executable-N block of code defined separately from where they are used. In the HTML format,N this column is a hypertext link to the list of routines by file for this file. K
- Length: The total number of lines contained in routinedK definitions, including blank lines and comments. Lines appearing outside ofpC routine definitions, such as external declarations, global variableM: declarations, and lines between routines are not included. O
- Avg Len: The average length of each routine defined in theo file. O
- # Calls: The total number of calls to any routines made inl the file.(
x%
Defined Routines By File
c I The list of defined routines by files report shows, for each source file,xN statistics for the routines in that file. The routines are listed in the orderG in which they occur in the file. The following is a sample for the file/, containing the analyzer's C language parser:0F ---------------------------------------------------------------------- D +- Link to annotated source for the, / routine.F / +- Link to crossF CPARSER.C Routines / / reference forE v v the routine. 7 =======================================================o6 # Times7 Routine Line Length Calls CalledC7 -------------------------------------------------------07 trace_parser 124 17 4 3T7 trace_parser_int 143 22 4 217 trace_parser_state 167 22 4 1 7 new_source_line 191 37 5 1X7 iskeyword 230 24 1 1A7 get_token 256 260 10 1R7 c_parser 518 186 13 0o7 -------------------------------------------------------o+ TOTAL: 7 ROUTINES 81 AVGa7 =======================================================L F ----------------------------------------------------------------------! The columns in this table are:
D
h*- Routine: The routine name as found in the file. L
- Line: The line at which the routine definition started.P In the HTML format, this column is a hypertext link to the routine definition in the annotated source code. M
- Length: The total length of the routine, including blanke lines and comments. L
- # Calls: The total number of routine calls made by this routine. M
- Times Called: The total number of times this routine wasyO called. A value of 0 may indicate that this routine is not used, or it may meaneP the routine is available for other code, not included in this analysis, to call.J In the HTML format, this column is a hypertext link to the cross reference information for the routine.
Defined Routines Alphabetical
J The alphabetical list of defined routines report shows statistics for eachN individual routine. This is the same information shown in the defined routinesN by file report, just organized differently. All routines defined in all of theO source files are listed in a single table, in alphabetical order. The following C is an abbreviated sample of the analyzer's defined routine list:
H ------------------------------------------------------------------------ D Link to cross reference -+E Defined Routines Alphabetical for the routine \=F vH ========================================================================G # Times-H Routine Line Length Calls CalledH ------------------------------------------------------------------------H add_caller - OBJECTS.H 231 1 1 2H add_def - GLOBDB.H 244 1 1 1H add_file - GLOBDB.H 243 1 1 1H add_lang - OBJECTS.H 99 1 2 6H add_ref - OBJECTS.H 228 1 1 2H add_srcref - OBJECTS.H 163 1 1 1H analyze_file - RANALYZER.C 101 144 41 1H analyze_product - RANALYZER.C 247 114 57 1H append_list_entry - LIST.H 53 1 2 4H assign_byfilefiles - RPTHTML.C 97 25 6 1H assign_xreffiles - RPTHTML.C 70 25 7 1H bliss_parser - BLIPARSE.C 561 178 38 0H block_level_dec - PARSER.H 41 1 1 4H block_level_inc - PARSER.H 40 1 1 2H block_level_zero - PARSER.H 39 1 1 3H byfile_link_prefix - RPTHTML.C 413 29 3 1H byfile_link_suffix - RPTHTML.C 28 1 1 1H c_parser - CPARSER.C 518 186 43 0 .1 . . H tree_link - RPTHTML.C 152 1 1 0H tree_size - REPORTS.C 364 39 11 0H url_prefix - GLOBDB.H 140 1 0 2H ustrcpy - BLIPARSE.C 282 25 1 5H ustrncmp - CMDOPT.C 36 36 4 8H xref_link - RPTHTML.C 382 29 4 4H xref_link_prefix - RPTHTML.C 340 40 7 8H xref_link_suffix - RPTHTML.C 27 1 1 8I -------------------------------------------------------------------------i TOTAL: 510 routines"I =========================================================================o I -------------------------------------------------------------------------aK
t +- Routine: The routine name, including the file name. If N there are multiple definitions for the same routine name, the name will appearL once for each definition, showing a different file or line number each time. L
- Line: The line at which the routine definition started. M
- Length: The total length of the routine, including blanku lines and comments.t L
- # Calls: The total number of routine calls made by this routine. M
- Times Called: The total number of times this routine wasnO called. A value of 0 may indicate that this routine is not used, or it may meanhP the routine is available for other code, not included in this analysis, to call.J In the HTML format, this column is a hypertext link to the cross reference information for the routine.
External Routines Alphabetical
O The alphabetical list of external routines reports shows the routines called bynO the source code which are not defined in the source. These are also referred tocO as undefined routines. They generally are defined in source or object libraries N which are included by the source or linked with its object code. They may alsoF be routines which have not yet been written, are defined in files thatO were not excluded from the analysis, or are written in a language for which the L analyzer does not have a parser. The following is a sample of the analyzer's external routine list:e
u> -------------------------------------------------------------- > +- Link to cross> Undefined Routines Alphabetical / reference for= v the routine.d0 ================================================/ Timesd0 Routine Called0 ------------------------------------------------0 atoi 30 calloc 10 def_treefile 40 fclose 220 fgetc 90 fgets 90 fopen 170 fprintf 1610 fputc 30 fputs 1470 free 10 freopen 10 fseek 10 isalnum 60 isalpha 30 isdigit 40 isspace 60 malloc 20 printf 1290 puts 160 sprintf 200 strcat 20 strcmp 90 strcpy 200 strlen 290 strncpy 10 toupper 50 ungetc 150 ------------------------------------------------ TOTAL: 28 routines0 ================================================ > --------------------------------------------------------------! The columns in this table are:
/
0- Routine: The routine name. M
- Times Called: The total number of times this routine was H called. In the HTML format, this column is a hypertext link to the cross& reference information for the routine.
Caller Cross Reference Alphabetical
L The caller cross reference report shows the callers of each routine, and theP call tree for each defined routine. In the HMTL format, the file name portion ofN the header line for each entry is a hypertext link to the routine's definition in the annotated source code.D The following are example cross reference entries for three routines0 illustrating three different situations. RoutineM product_name is a simple routine (actually a macro) that does not calleH any others. Routine puts is a standard C library routine. Routine? remove_lang is a routine with a call tree three routinesd deep.
lA -----------------------------------------------------------------t A +- Link to annotated source for the routine.l /t v product_name - GLOBDB.HM 8 Callers Link to cross reference -+9 for the routine \oL 3 callers v < + list_product_begin - LISTFILE.C Goto< + rpt_html_section_hdr - RPTHTML.C Goto< + rpt_html_section_title - RPTHTML.C Goto Call Tree: No callss A -----------------------------------------------------------------b puts - External Callersr 7 callersu< + bliss_parser - BLIPARSE.C Goto< + cmdopt_fmt_kwhandler - RANALYZER.C Goto< + main - RANALYZER.C Goto< + new_def - OBJECTS.C Goto< + report_source - REPORTS.C Goto< + report_tree - REPORTS.C Goto< + show_help - RANALYZER.C Goto A ----------------------------------------------------------------- remove_lang - OBJECTS.Ha Callers- 1 caller< + get_parser - RANALYZER.C Goto Call TreeS remove_lang | dequeue_entry Goto | | remove_list_entry Goto | | | isfirst_entry Goto | | | + entry_blink Goto | | | set_list_first Goto | | | entry_flink Goto | | | set_entry_flink Goto( | | | entry_blink (Duplicate) Goto | | | islast_entry Goto , | | | + entry_flink (Duplicate) Goto | | | set_list_last Goto | | | set_entry_blink Goto! | | + dec_list_entries Goto | + list_first Goto + global_langlist Goto END OF TREEE A -----------------------------------------------------------------I" The items in these figures are:
G
D L Note that a call tree illustrates the general structure and potentialO flow of control, but does not show exact execution flow. This is becauseCN it does not show control structures such as if-then branches or loops. While aO call tree may list several called routines in a row, you cannot assume they are-N called in that order, because there may be conditional logic altering the flow of execution.= "- Callers: The list of routines which call this one,sM including their file names. In the HTML format, the word "Goto" at the end ofaP the line is a hypertext link to the cross reference information for that caller. M
- Call Tree: The call tree of routines called by this one.RL Indentation and "|" markers reflect the call level in the tree. A "+" markerF means that the rotuine is the last one called at that level. The wordsP "External", "Separate", or "Duplicate" enclosed in parenthesis indicate that theO called routine is external, is expanded only in its own separate call tree (not O inline in this tree), or is a duplicate call already expanded in this tree. For P brevity, a given routine is shown only once at any level of the tree, regardlessO of how many calls to it a routine contains. In the HTML format, the word "Goto"0M at the end of the line is a hypertext link to the cross reference information for that called routine.
Annotated Source Code
M The annotated source code report shows, for each source file, an alphabeticaloF index of the routines defined in the file, and the actual source code,J with line numbers. The begin and end points of each routine definition areP clearly labeled. The following is an abbreviated example of the annotated sourceJ code from the analyzer's main module, showing the beginning and end of the annotated listing:eP -------------------------------------------------------------------------------- RANALYZER.C Source Codea $ Routines In This File (Alphabetical) Line Name ----- ---- 101 analyze_file 247 analyze_productm 1037 cmdopt_author . . . 31 get_parser 1121 main 1052 show_helpo BEGINNING OF FILEo V 1: /****************************************************************************/V 2: /* */V 3: /* FACILITY: Routine Analyzer */V 4: /* */V 5: /* MODULE: Main Module */V 6: /* */V 7: /* AUTHOR: Steve Branam, Network Product Support Group, Digital */V 8: /* Equipment Corporation, Littleton, MA, USA. */V 9: /* */V 10: /* DESCRIPTION: This is the main module for Routine Analyzer. It contains */V 11: /* the main routine, command option handlers, and the main application */V 12: /* routines for processing product and source files. */V 13: /* */V 14: /* REVISION HISTORY: */V 15: /* */V 16: /* V0.1-00 24-AUG-1994 Steve Branam */V 17: /* */V 18: /* Original version. */V 19: /* */V 20: /****************************************************************************/ 21: V 22: #define MAIN_MODULE /* This is the main module. */ 23: #include! The columns in this table are:24: #include "ranalyzer.h" 25: 26: + 27: extern language_element c_parser(); / 28: extern language_element bliss_parser(); 29: V 30: /*************************************************************************++*/ ROUTINE get_parser. 31: PARSER get_parser(V 32: /* Returns the parser function appropriate for the source language, based */V 33: /* on the file name extension. */ 34: ! 35: char *aSourceName, V 36: /* (READ, BY ADDR): */V 37: /* Source file name string. */ 38: ! 39: char **aParserName V 40: /* (WRITE, BY ADDR): */V 41: /* Parser name string ptr, set to parser name string. */ 42: V 43: ) /* Returns ptr to parser function. */V 44: /*****************************************************************--*/ 45: 46: {SV 47: KEYWORD_DEFINITION /* Current keyword definition. */ 48: *curkwdef;V 49: LANGUAGE_TRANSLATION /* Current language trans. */ 50: *curtrans;V 51: char *extstr; /* File extension ptr. */ 52: - 53: if (global_langtable() == NULL) {e@ 54: set_lang_table(list_entries(global_langlist()));3 55: for (curkwdef = global_langtable();i7 56: (curtrans = remove_lang()) != NULL; ! 57: curkwdef++) { E 58: set_kwdef_keyword(curkwdef, lang_fext(curtrans));iL 59: set_kwdef_minlen(curkwdef, strlen(lang_fext(curtrans)));B 60: set_kwdef_code(curkwdef, lang_code(curtrans));( 61: free_lang(curtrans); 62: }r 63: }< 64: 65: V 66: /*+ */V 67: /* Scan back from end of file name string for file extension. If not */V 68: /* found, can't identify parser. Otherwise, locate end of extension */V 69: /* string and compare it to known file extensions. */V 70: /*- */ 71: < 72: for (extstr = &aSourceName[strlen(aSourceName)];G 73: extstr >= aSourceName && *extstr != FILE_EXT_SEPARATOR; 74: extstr--);' 75: if (extstr < aSourceName) {-X 76: printf("ERROR: No file extension specified for file %s\n", aSourceName); 77: return NULL; 78: } 79: else { 80: extstr++;wH 81: switch (translate_keyword(extstr, global_langtable())) {V 82: case LANGUAGE_UNKNOWN: /* No matches on file type. */ 83: printf(PN 84: "ERROR: Unable to identify source language for file %s\n",% 85: aSourceName);N 86: return NULL; 87: break; 88: case LANGUAGE_C:' 89: *aParserName = "C"; $ 90: return c_parser; 91: break;$ 92: case LANGUAGE_BLISS:+ 93: *aParserName = "BLISS";e( 94: return bliss_parser; 95: break; 96: } 97: }i 98: }t END get_parser. .n .o . ROUTINE main. 1121: main( V 1122: /* Program main routine. */ 1123: 1124: int vArgc,V 1125: /* (READ, BY VAL): */V 1126: /* Number of program argument strings in aArgv. */ 1127: 1128: char *aArgv[]V 1129: /* (READ, BY ADDR): */V 1130: /* List of program argument strings. */ 1131: V 1132: ) /* Returns system success code. */V 1133: /*****************************************************************--*/ 1134: 1135: { V 1136: /* Main program command line */V 1137: /* argument options dispatch */V 1138: /* table. */3 1139: static KEYWORD_DEFINITION options[] = {i9 1140: {"options", 3, process_options_file},n1 1141: {"trace", 3, cmdopt_trace}, 4 1142: {"log", 3, cmdopt_log}, 4 1143: {"list", 3, cmdopt_list}, E 1144: {"silent", 3, cmdopt_set, LOG_SILENT_ENABLE}, E 1145: {"brief", 3, cmdopt_set, LOG_BRIEF_ENABLE}, t5 1146: {"outprefix", 3, cmdopt_outprefix},i2 1147: {"format", 3, cmdopt_format},7 1148: {"description", 3, cmdopt_description}, @ 1149: {"definition", 3, cmdopt_set, LOG_DEF_ENABLE},@ 1150: {"reference", 3, cmdopt_set, LOG_REF_ENABLE},4 1151: {"separate", 3, cmdopt_separate},4 1152: {"language", 3, cmdopt_language},E 1153: {"noinline", 3, cmdopt_set, TREE_INLINE_DISABLE},h5 1154: {"urlprefix", 3, cmdopt_urlprefix},i3 1155: {"callers", 3, cmdopt_callers},n2 1156: {"report", 3, cmdopt_report},4 1157: {"noreport", 3, cmdopt_noreport},6 1158: {"htmlbyfile", 5, cmdopt_htmlbyfile},4 1159: {"htmlxref", 5, cmdopt_htmlxref},2 1160: {"author", 3, cmdopt_author},V 1161: {NULL, 0, NULL} /* End of table. */ 1162: }; 1163: V 1164: /*+ */V 1165: /* Make sure enough reqired arguments were specified, then process the */V 1166: /* optional arguments and analyze the product files. */V 1167: /*- */ 1168: 1169: if (vArgc < 3) {D 1170: if (vArgc > 1 && *aArgv[1] == CMDLINE_HELP_SWITCH) { 1171: show_help(); 1172: } 1173: else {) 1174: puts(PROGRAM_PARAMS); ' 1175: puts(PROGRAM_HELP); 1176: } 1177: } 1178: else {V 1179: /* Disable these reports by */V 1180: /* default. */B 1181: set_option(RPT_CALLS_DISABLE | RPT_TREES_DISABLE); 1182: 1 1183: set_max_callers(DEF_MAX_CALLERS); 9 1184: set_max_html_byfile(DEF_MAX_HTML_BYFILE);E5 1185: set_max_html_xref(DEF_MAX_HTML_XREF);.@ 1186: if (process_options(vArgc, aArgv, 2, options)) {8 1187: add_lang(new_lang("C", LANGUAGE_C));8 1188: add_lang(new_lang("H", LANGUAGE_C));> 1189: add_lang(new_lang("BLI", LANGUAGE_BLISS));> 1190: add_lang(new_lang("REQ", LANGUAGE_BLISS));> 1191: add_lang(new_lang("R32", LANGUAGE_BLISS));. 1192: analyze_product(aArgv[1]);) 1193: if (list_enabled()) { , 1194: fclose(list_file()); 1195: } 1196: }* 1197: } 1198: } END main. 1199: END OF FILE ! TOTAL: 23 routines, 49 Avg Lengthi P --------------------------------------------------------------------------------
- :
- :
- :
- :
- :
s,Quick Tips On Mosaic Navigation
P Because Routine Analyzer produces a set of hyperlinked HTML files, here are someL quick tips on navigation to help browse them with NCSA Mosaic, beyong simpleJ scrolling and hyperlink jumps (other browsers may or may not have the same% capabilities and interface controls):a
l- Go to end of HTML file: Click mouse button 1 below the thumb in the vertical ' scroll bar while pressing the CTRL key.x ^
- Go to beginning of HTML file: Click mouse button 1 above the thumb in the0 vertical scroll bar while pressing the CTRL key. X
- Go to specific region of HTML file: Click mouse button 2 (or 3 on aP 3-button mouse) at the relative point in the vertical scroll bar where you wantM to go (remember that the scroll bar represents the entire length of the file, M and the thumb represents the portion currently displayed in the view window);tF the file will be positioned to that relative point in the view window. H
- Follow hyperlink using a new window, leaving original windowJ unchanged: Click mouse button 2 (or 3 on a 3-button mouse) on theE hyperlink. A new browser window will be created containing the linkedoN information; the window you linked from will remain unchanged. This allows youL to treat a window as a table of contents or map from which you can spawn newM windows to other locations; the hyperlinks in the Routine Analyzer HTML filessM have been organized to facilitate this usage. Just be careful of creating too ' many windows for your system to handle!e