Hi Phil,
I'm not in a position to "insist" on anything, and it's not a question of "proving a point". It seems to me that the combination of setjmp/longjmp, C++-calling-C-calling-C++, exceptions and destructors that is involved in this error-handling mechanism is going to poke into a buggy corner on at least one of the platforms that Boost claims to support, and it would be much better for that to be detected during testing, rather that when a user accidentally tries it on a production system.
I would also say that if you have gone to the trouble of creating test images that are corrupted in sufficiently subtle ways to trigger these error paths, then it would be valuable to make them public.
My corrupted images were merely .txt files. ;-) When reading the header libjpeg would issue an error and the io extension will throw an exception. Now, we can argue such testing is insufficient and I would agree but that's what we have for now. I'm gladly incorporate some corrupted image reading into the test suite. Christian