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@ics.uci.edu' for information.