Getting this back to LCMS 2.0. Looking at the code there have been some significant changes in 2.0. For example it still has cmsSetErrorHandler() but this is for backward compatibility and it now has support for creating an error handler plug-in that appears to have more functionality although it may not have fixed the underlying issues.
The version 1.x error handling code has a number of problems. 1. The calling app can set the default behavior using cmsErrorAction() and one of the values is LCMS_ERROR_SHOW. But setting it to LCMS_ERROR_SHOW has no affect on the code path and acts just like the default setting of LCMS_ERROR_ABORT. 2. Setting LCMS_ERROR_IGNORE will result in segmentation faults in some cases because the error is not handled. Actually the existing error handling code never really handles the error all it does is aborts execution if there is an error. 3. If a user defined error handler is setup and the user supplied error handler does not short circuit the call chain with something like a setjmp() then execution returns to the statement after the call to the error handler(s) and in many cases this will result in a segmentation fault in the LCMS code. So the only realistic option is for the user supplied error handlers to short circuit the call chain to prevent LCMS from continuing on and seg faulting.. It is this situation that is the root problem that is causing application to use things like setjmp(). How can we tell LCMS to not abort and still not seg fault while returning to the place where the user application invoked LCMS? Now looking at the error handling code in LCMS 2 it is all new code and even the cmsSignalError() function is completely different code. But like the older code it's default behavior is the same if LCMS_ERROR_SHOW or LCMS_ERROR_ABORT are set as the default action by the user app. In addition the new error handler plug-in functionality allows the calling application to set up three entry points for handling errors and warnings. One each to handle errors, warnings and a function that is called to handle exit conditions. So this is more flexible but I am not sure how this can deal with situations where the user app wants to continue but doing so by letting LCMS continue will cause a seg fault or some other major error. I am not sure how to solve this issue but unless LCMS 2 will not seg fault when the user app sets LCMS_ERROR_IGNORE or it uses a user provided error handler that effectively does the same thing then we still have the same basic issue. How can this be setup to return control to the statement after the call to LCMS that raised the error condition without LCMS seg faulting? For what it's worth I think the current LCMS way of doing this is, just barely, OK for command line line programs but it has major issues for those writing applications where aborting execution is NOT an option like in GUI apps (Scribus, LProf. Krita, Digikam, UFRAW, XSane...). For those applications we need a way to trap errors so that they can be handled gracefully. We can do this with setjmp() but this is very ugly and has many issues including that it is only available is some languages and is not well suited to multi-threaded applications. Hal ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ Lcms-user mailing list Lcms-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lcms-user
