Release Notes

Open Source Used In AsyncOS 8.8 for Cisco Web Security Appliances
74
application regain control after an error rather than exiting.
The JPEG library never writes any message directly; it always goes through
the error handling routines. Three classes of messages are recognized:
* Fatal errors: the library cannot continue.
* Warnings: the library can continue, but the data is corrupt, and a
damaged output image is likely to result.
* Trace/informational messages. These come with a trace level indicating
the importance of the message; you can control the verbosity of the
program by adjusting the maximum trace level that will be displayed.
You may, if you wish, simply replace the entire JPEG error handling module
(jerror.c) with your own code. However, you can avoid code duplication by
only replacing some of the routines depending on the behavior you need.
This is accomplished by calling jpeg_std_error() as usual, but then overriding
some of the method pointers in the jpeg_error_mgr struct, as illustrated by
example.c.
All of the error handling routines will receive a pointer to the JPEG object
(a j_common_ptr which points to either a jpeg_compress_struct or a
jpeg_decompress_struct; if you need to tell which, test the is_decompressor
field). This struct includes a pointer to the error manager struct in its
"err" field. Frequently, custom error handler routines will need to access
additional data which is not known to the JPEG library or the standard error
handler. The most convenient way to do this is to embed either the JPEG
object or the jpeg_error_mgr struct in a larger structure that contains
additional fields; then casting the passed pointer provides access to the
additional fields. Again, see example.c for one way to do it. (Beginning
with IJG version 6b, there is also a void pointer "client_data" in each
JPEG object, which the application can also use to find related data.
The library does not touch client_data at all.)
The individual methods that you might wish to override are:
error_exit (j_common_ptr cinfo)
Receives control for a fatal error. Information sufficient to
generate the error message has been stored in cinfo->err; call
output_message to display it. Control must NOT return to the caller;
generally this routine will exit() or longjmp() somewhere.
Typically you would override this routine to get rid of the exit()
default behavior. Note that if you continue processing, you should
clean up the JPEG object with jpeg_abort() or jpeg_destroy().
output_message (j_common_ptr cinfo)
Actual output of any JPEG message. Override this to send messages
somewhere other than stderr. Note that this method does not know
how to generate a message, only where to send it.