Subject: Re: [boost] gil::io "non-review" (was: [gil] Can not open test.jpg)
From: Christian Henning (chhenning_at_[hidden])
Date: 2010-03-24 11:41:45
Hi Phil, first of all thanks for raising these issues. I believe it's
very helpful for my submission.
>> Does that mean I have to call setjmp everytime before I call libjeg
>> function? This way the function that calls setjmp would not have been
> Your choices are:
> 1. setjmp() in each function (scope?) that calls into libjpeg. That's nasty
> because setjmp(), IIRC, is detected by the compiler and prevents some
> optimisations. It's relatively non-intrusive in your code though.
In my opinion this is the best option I have right now.
> 2. setjmp() once, and make sure that that is in a scope that contains all
> the calls. This means turning your code inside out, but it's not impossible
> because - as we've noted - you never leave a jpeg file open and return to
> the user code, i.e. the setjmp() can happen soon after the user calls into
> your code. I don't think that destructors will not be called when longjmp()
> "pops" the stack, so you need to be careful about what types you use.
This would turn my code into an ugly huge switch statement, with a lot
of code repetition. I rather not do that.
> 3. (deleted - idea too horrible to share.)
Don't even wanna know. ;-)
> 4. Try to throw an exception from the error handler. This would be ideal,
> if you could be sure that the exception would propagate through the C code.
> I believe that gcc has an option to control that. I have a feeling that it
> is enabled for some libraries in Debian precisely to support this sort of
> thing. I know nothing about other compilers, and even on Linux it's
> probably not reasonable to expect that the user will use a libjpeg compiled
> in this way.
I agree this would be support nightmare. We all know that the user
wants something workable out-of-box.
> 5. (Grasping at straws) run libjpeg in a co-routine, err, not sure exactly
> how that would work, but something about an extra stack...
I'm already drowned. Maybe someone else on this mailing list can go
into more details.
> 6. This is what I'd really like to see: copy the libjpeg source into your
> project, and then do (4). You could do some other tidying-up at the same
This is only possible if I have someone who is willing to put the time
and effort in. I don't have that right now. Leaving for loooooooong (
2 months ) vacation soon. Also, do you know whether or not libjpeg
What I could see is to have a separate project that provides an
"updated" libjpeg source. For such users we could provide a compiler
symbol to compile optimized code. I'll keep this option in mind.
> My recollection is that one of the other libraries also had a setjmp error
> handler, but that it could be configured to instead return error codes while
> libjpeg can't. Not sure if that's accurate though.
Do you mean libpng? I believe I have to update my code for png, as well.