Go to the previous, next section.

Known Bugs and Limitations with gperf

The following are some limitations with the current release of gperf:

• The gperf utility is tuned to execute quickly, and works quickly for small to medium size data sets (around 1000 keywords). It is extremely useful for maintaining perfect hash functions for compiler keyword sets. Several recent enhancements now enable gperf to work efficiently on much larger keyword sets (over 15,000 keywords). When processing large keyword sets it helps greatly to have over 8 megs of RAM.

  However, since gperf does not backtrack no guaranteed solution occurs on every run. On the other hand, it is usually easy to obtain a solution by varying the option parameters. In particular, try the `-r' option, and also try changing the default arguments to the `-s' and `-j' options. To guarantee a solution, use the `-D' and `-S' options, although the final results are not likely to be a perfect hash function anymore! Finally, use the `-f' option if you want gperf to generate the perfect hash function fast, with less emphasis on making it minimal.

• The size of the generate static keyword array can get extremely large if the input keyword file is large or if the keywords are quite similar. This tends to slow down the compilation of the generated C code, and greatly inflates the object code size. If this situation occurs, consider using the `-S' option to reduce data size, potentially increasing keyword recognition time a negligible amount. Since many C compilers cannot correctly generated code for large switch statements it is important to qualify the -S option with an appropriate numerical argument that controls the number of switch statements generated.

• The maximum number of key positions selected for a given key has an arbitrary limit of 126. This restriction should be removed, and if anyone considers this a problem write me and let me know so I can remove the constraint.

• The C++ source code only compiles correctly with GNU G++, version 1.36 (and hopefully later versions). Porting to AT&T cfront would be tedious, but possible (and desirable). There is also a K&R C version available now. This should compile without change on most BSD systems, but may require a bit of work to run on SYSV, since gperf uses alloca in several places. Send mail to schmidt at ics.uci.edu for information.

Go to the previous, next section.