BUGS & FEATURES
---------------
o There can be remaining bugs in compression modules for really
  small files (less than 100 bytes). In particular, if compression
  is not efficient (negative compression rate), it won't be detected.
o No destruction of crunched file is made when something goes wrong in
  the library. But in ``crunch'' and ``decrunch'', output files are
  deleted if there is an error. Thus, it's up to you to destroy
  output files if compression/decompression goes wrong.
o No tmp file is created when decrunching... If the decrunch process
  goes wrong, you can loose your original file. IN NO WAY AM I
  RESPONSIBLE FOR DATA LOST WITH THIS LIBRARY. This said, if you
  have a problem, contact me, I'll do everything I can to solve it.
  Please, when you can, send me a bug report, along with the problematic
  file (if it's not too big), so I can see where it goes wrong.
  Simply run the "bug-report" script (if it doesn't loop), and mail
  me the result.
o If the library is memory short (that is, there is no more free memory),
  it does an exit. This can be harmful if you use the crunch library in
  your program, in case you _trap_ this kind of error to do something...
  I could have made a perror, then a SIG_SEGV so one could trap this
  signal. I could have... If you find this useful, simply edit the
  ``common.c'' file, more precisely the "Malloc" function. There is
  an error case if the ``malloc'' call fails. Modify it...
  Suggestion:
    if (!p) {
        ERROR("Cannot allocate memory!");
        perror("Reason");
	printf(NULL);
    }
  This one makes a beautiful SIG_SEGV! :-)
  You can also use the ``atexit'' function, which is really useful...
o There are still _3_ other ``exit'' calls in the library, in ad_huff.c,
  huffman.c and in lzss.c. These calls are made when something _really_
  goes wrong (in the algorithm), and may never happen. May... If you get
  a message like:
	Error: Bug in module [...]: [...]
  Send me a bug-report (it's my fault...).
o Library may display some error messages to standard error, if
  it's really a serious error. If this bother you, edit the common.h
  file, find the #define of ERROR, and remove the action (ie the
  fprintf to stderr). This will suppress the error messages, but
  won't affect library functions. Then re-compile and re-install.



TESTED ON...:
-------------
o These programs and library were successfully tested on the following systems:
  -Linux 2.0 on Pentium PC
  -Solaris 2.4 on Sparc10/20
  -Solaris 2.5 on UltraSparc 1
  -Irix 6.2 on Indy (R5000)
o If you achieved a compilation without bugs on another system, please let
  me know about it. If it didn't compile, let me know too (launch a bug-report
  and mail me the result...).



USELESS NOTES FOR FUN:
----------------------
o The library is as correct as it can with memory. This means that it
  _does_ free all memory blocks allocated during its run, even in case
  of errors (except, of course, ``not enough memory'' errors. See the
  bug section). This means that you can use the library as many times
  as you want, your program won't leak memory because of unfred blocks.
  By the way, the library still uses a bunch of memory blocks in many
  modes. Here are (roughly) the amount of memory currently allocated by
  the different modules:
	ad_huff.c	18Kb
	huffman.c	20Kb
	lzw.c		53Kb
	lzss.c		76Kb
  plus 10 to 20% for heap allocation in function calls...
o I'm trying my best to make useful libs. If you think you have a better
  interface for crunching files, let me know. Two can make what one can't.
o The crunch and decrunch programs have been longly tested with the
  purify tools. I have also used prolint on files, and corrected as
  many problems as I could. Not to mention logiscope, to test the
  quality of the code (which is, I must confess, poor...)
  This doesn't mean the library is bug free, but many have been corrected.
  This means I know write (void)fprintf instead of fprintf :-)



TODO:
-----
o In Lzw:
    -Better intelligence in reset table:
       o LRU
       o NRU
o In Ad. Huffman:
    -Variable block length
    -Byte compression
    -Block compression
o Fixed length block compression
o Q-Coding
o B-Trees
o More statistic compression methods
    -Shano Fannon
    -Huffman on character pairs
    -Tiny huffman for really small compression (on less than 8 bits)
o Weinberger Hash function
o More control flags:
    -Check
    -Verbose
o Archive capabilities
o Curses interface in cruncher and decruncher
