z (06/23/82)
A couple of years ago, I wrote a cref (cross reference) program for Unix which worked very much like the standard DEC crefs. For example, if you said "cref e_qreg.c", you would get on the standard output a listing identical to that produced by the num(1) command, followed by a cref table which looks like so: Jun 21 12:20 1982 Cref listing Page 1 BKILL 29 EOL 88 FKILL 27 KBSIZE 79 89 91 NQREG 19 41 61 QMARK 68 172 204 218 QNUM 65 151 167 191 QRECT 76 105 QREG 38 42 72 QSTRING 30 32 71 175 Qflag 30 32 65 68 71 76 105 151 167 172 175 191 204 218 WARN 34 152 173 176 219 appendq 13# 108 arg 13# 18 22 54# 60 145# 146# 155 162# 185# 186# 192 199# 213# atoi 192 beep 74 138 etc. The numbers are line numbers where the symbol is referenced; those followed by hash marks are lines where the symbol is defined. Symbols which are multiply defined are typically local variables used in several different routines. The output is designed for 132 column printers, so a couple of lines in the above example wrap around. When cref is invoked with multiple file names, it produces a single cref table for the entire list. I recently modified cref so that it now has an option to produce a tags table identical in form to that produced by ctags. Its advantage over ctags is that variables and macros appear in it, as well as functions. This tags table can be used in any program that uses the output of ctags. Since variables are sometimes defined in several different places (such as "arg" in the above example), some programs which use tags tables may not be able to find the occurrence you are looking for. However, users of my EMACS will find that its tags package is set up to resolve such ambiguities. I have posted the source and manual page for cref to net.sources. Although cref was written for 4BSD, it should work rather well on other Unixes. However, the fact that it uses virtual memory for its cref table may limit the size of programs that it can work on under other Unixes.