--- name: "csize" section: "1" platform: "linux" package: "metrics" version: "1.0-1" release: "Debian 2.2 (Potato)" platforms: ["linux"] url: "https://new.carta.tech/csize" --- # csize(1) measure the size of C source files ## NAME csize - measure the size of C source files ## SYNOPSIS **csize** \[ **-ehv** \] *filename.c* \[ ... \] ## DESCRIPTION **csize** performs lexical analysis on the named C source files to collect several size measures, keeping a total count for all files. Use of **csize** is superior to **wc** because in addition to newline counts, the user can measure code density, commenting, and use of the preprocessor. Both old-style (K&R) and new-style (ANSI) C files are accepted. The C preprocessor is *not* run, and preprocessor directives are counted instead of being expanded. The program was designed to measure the source as the programmer sees it. The input is expected to be acceptable for a C compiler; lexically incorrect input will cause unreliable output ("GIGO"). The program has much of the functionality of a C preprocessor. The logically successive phases described in K&Rrev2 which a preprocessor must implement are implemented in the form of a single pass over the input. ## OPTIONS - **-e** Echo the input file while it is being processed. - **-h** Include a descriptive header when printing the results. - **-v** Report version information (all other arguments are ignored). ## MEASURES **csize** collects data for the following size measures of C source code: total lines, blank lines, lines with comments, nonblank noncomment lines, semicolons, and preprocessor directives. A line is defined as the sequence of characters between two newline characters. The sole exception to this definition is the first line of a file, which starts at the beginning of the input file. The last line is expected to be terminated by a newline character. - **total lines** The number of newline characters in the file. This is identical to the result computed by *wc* with the lines ("-l") option. (However, if it were sufficient to use *wc ,* this program would be wholly unnecessary!) Pitfalls: arguably a poor measure of a file's size, because this measure is heavily influenced by bracing style, spacing, and continuation lines. - **blank lines** The number of lines in the file with nothing but white-space characters between the previous newline character and the newline that terminates the line. A white-space character is defined as a blank, a horizontal tab, a vertical tab, or a form-feed character. Pitfalls: blank lines within comments are counted as lines with comments. A blank line as a preprocessor continuation line will terminate the directive and is therefore counted not as a blank line but as a nonblank noncomment line. - **lines with comments** The number of lines on which a comment occurs. The appearance of a comment anywhere on a line causes that line to be marked as having a comment. Any number of comments, each with its own start token ("/\*") and end token ("\*/"), may occur on a single line; the line will only be counted once. If a comment extends over multiple lines, each line is counted as having a comment. Pitfalls: in C, unlike FORTRAN, there is no such thing as a pure comment line. Comments can appear before, within, or after normal C statements on the same line as the statements, as well as on lines of their own. Therefore the sum of the measures "lines with comments," "blank lines," and "noncomment nonblank lines" will only sometimes be equal to the measure "number of newlines," and then only by chance. See also the discussions in **blank lines** and **preprocessor directives** in regard to counting lines with comments. - **nonblank noncomment lines** The number of lines that are not blank and do not consist entirely of a comment. This includes preprocessor directives. This measure approximates the number of nonblank, noncommentary source lines (often labeled NCSL) in a C source file. Pitfalls: This measure includes lines with nothing but curly braces, so choosing a different bracing style can affect this measure significantly. - **semicolons** The number of semicolons that do not appear in string constants. This measure approximates the number of variable declarations, function prototypes, and executable statements in a C source file. Pitfalls: Although most statements are terminated with a semicolon, function headers have no semicolons, "while" statements and "case" statements can be written with a bare minimum of semicolons, and a single for statement has a minimum of two semicolons. See also the discussion in **preprocessor directives** in regard to counting semicolons. - **preprocessor directives** The number of occurrences of the hash sign ("#"), followed by optional white-space characters, followed by a preprocessor keyword, followed by any characters up to the next nonescaped newline. The following keywords are recognized: define, undef, include, line, error, pragma, endif, if, ifdef, ifndef, elif, or else, include\_next, import, warning, sccs, ident, assert, unassert. Again, the preprocessor is not run: included files are not pulled in, no macro substitutions are done, etc. Pitfalls: The hash sign does not have to be the first non-white-space character on a line. Comments that begin on the same line as a preprocessor directive are processed until the closing comment token, and then processing of the preprocessor directive resumes. Other than comments, all characters between the preprocessor keyword and the next nonescaped newline are ignored, so any other preprocessor directives or semicolons on the same line are not counted. See also the discussion in **blank lines** in regard to counting preprocessor directives. ## EXAMPLE A version of the hello, world program is measured in this example. ``` % cat hello.c /* hello, world */ #include int main(argc, argv) /* what about envp? */ int argc; char **argv; { printf("hello, world.0); } % csize -h hello.c total blank lines w/ nb, nc semi- preproc. file lines lines comments lines colons direct. --------+--------+--------+--------+--------+--------+---- 9 1 2 7 3 1 hello.c ``` ## DIAGNOSTICS The program will complain about lexical errors such as an unescaped newline character inside a string constant or an end-of-file condition within a comment. ## BUGS This entire program can justifiably be considered called a bug, because these measures should be computed by the C compiler. Compiler support is required to count declarations and executable statements. The measures are strongly tied to the newline character. If the last character in the file is not a newline (users of *emacs* should be familiar with this phenomenon), then the last line will not be counted in accordance with one's intuition. In other words, nonblank noncomment text on the last line will not cause the appropriate counter to be incremented. ANSI-style trigraphs are not supported. Neither dollar signs ($) nor at signs (@) are accepted in identifiers. There are certainly pathological cases out there that will confuse the program, although they are accepted by a C compiler. The author would much appreciate being told of such cases and any possible remedies. ## SEE ALSO [wc(1)](/wc/1.md), [lc(1)](/lc/1.md) by Brian Marick, [kdsi(1)](/kdsi/1.md) by Brian Renaud, \_The C Programming Language\_ by Brian W. Kernighan and Dennis M. Ritchie, Prentice Hall, 1988. ## AUTHOR Christopher Lott \