Re: [boost] gil::io "non-review" (was: [gil] Can not open test.jpg)

Subject: Re: [boost] gil::io "non-review" (was: [gil] Can not open test.jpg)
From: John Bytheway (jbytheway+boost_at_[hidden])
Date: 2010-03-24 15:49:10

Phil Endecott wrote:
> Hi Christian,
> 
> I wonder if anyone will notice this message amid all the mud and
> flame-slinging that's going on?  I know - I'll get everyone's attention
> by pointing out that the fundamental problem here is that the C library,
> libjpeg, has a truly awful API design: when it gets an error, it calls a
> user-supplied function-pointer and that mustn't return.

Yes, that's pretty abominable.

> Christian Henning wrote:
>> 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
>> terminated.
> 
> 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.

I can't believe performance is a serious concern here.  I think this is
the best option.  There's still the thread-safety issue.  Can you use
the cinfo to pass the jmp_buf through to error_exit? If not then I guess
the jmp_buf could be stored in static thread-local storage...

> 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.

Yes, that's undefined behaviour too; see e.g. N3000, [support.runtime] p4:

A setjmp/longjmp call pair has undefined behavior if replacing the
setjmp and longjmp by catch
and throw would invoke any non-trivial destructors for any automatic
objects.

> 5. (Grasping at straws) run libjpeg in a co-routine, err, not sure
> exactly how that would work, but something about an extra stack...

More trouble than it's worth, I'm pretty sure.

> 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 time.

Sounds nice in principle, but again the benefit over solution 1 is
minor, and the maintenance burden would surely be huge.  For example the
entire library would have to be put in a namespace or something so as
not to clash with the 'real' libjpeg.

John Bytheway