In a deeply embedded application, you might want to use just the memory-to-memory functions. You can do this conveniently by compiling the library with preprocessor symbol BZ_NO_STDIO defined. Doing this gives you a library containing only the following eight functions:

BZ2_bzCompressInit, BZ2_bzCompress, BZ2_bzCompressEnd BZ2_bzDecompressInit, BZ2_bzDecompress, BZ2_bzDecompressEnd BZ2_bzBuffToBuffCompress, BZ2_bzBuffToBuffDecompress

When compiled like this, all functions will ignore verbosity settings.

libbzip2 contains a number of internal assertion checks which should, needless to say, never be activated. Nevertheless, if an assertion should fail, behaviour depends on whether or not the library was compiled with BZ_NO_STDIO set.

For a normal compile, an assertion failure yields the message:

where N is some error code number. If N == 1007, it also prints some extra text advising the reader that unreliable memory is often associated with internal error 1007. (This is a frequently-observed-phenomenon with versions 1.0.0/1.0.1).

exit(3) is then called.

For a stdio-free library, assertion failures result in a call to a function declared as:

extern void bz_internal_error ( int errcode );

The relevant code is passed as a parameter. You should supply such a function.

In either case, once an assertion failure has occurred, any bz_stream records involved can be regarded as invalid. You should not attempt to resume normal operation with them.

You may, of course, change critical error handling to suit your needs. As I said above, critical errors indicate bugs in the library and should not occur. All "normal" error situations are indicated via error return codes from functions, and can be recovered from.