CSIZE(1)

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 <stdio.h>
int main(argc, argv) /* what about envp? */
int argc;
char **argv;
{
   printf("hello, world.);
}
% 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), lc(1) by Brian Marick, kdsi(1) by Brian Renaud, _The C Programming Language_ by Brian W. Kernighan and Dennis M. Ritchie, Prentice Hall, 1988.

AUTHOR
Christopher Lott <lott@informatik.uni-kl.de>