|
|
Boost : |
Subject: Re: [boost] gil::io "non-review" (was: [gil] Can not open test.jpg)
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2010-03-23 20:41:17
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.
Christian Henning wrote:
>> I agree with Phil; that's undefined behaviour. ?I can't access the
>> official C standard here, but in the C99 draft N1256
>> (http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf), in
>> 7.13.2.1p2, it says (of longjmp):
>>
>> ... if the function containing
>> the invocation of the setjmp macro has terminated execution in the
>> interim, ... the behavior is undefined.
>>
>> So, once try_something has returned, the effect of calls to longjmp is
>> undefined.
>>
>
> 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.
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.
3. (deleted - idea too horrible to share.)
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.
5. (Grasping at straws) run libjpeg in a co-routine, err, not sure
exactly how that would work, but something about an extra stack...
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.
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.
Regards, Phil.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk