[webkit-dev] Windows setjmp/longjmp issue

[Peter Kasting]

On Tue, Apr 27, 2010 at 2:33 PM, SCU Rock <scurock at gmail.com> wrote:

>    In WebCore/platform/image-
> decoders/jpeg/JPEGImageDecoder.cpp (
> https://trac.webkit.org/browser/trunk/WebCore/platform/image-decoders/jpeg/JPEGImageDecoder.cpp)
> and png/PNGImageDecoder.cpp, setjmp and longjmp are called. This causes this
> code unportable to Windows environment. At
> http://msdn.microsoft.com/en-us/library/xe7acxfb%28VS.80%29.aspx, it is
> mentioned that "setjmp and longjmp do not support C++ object semantics".


I believe that means that things like stack-allocated objects may not be
destroyed correctly (as opposed to when using C++ exceptions, which can make
more guarantees about object destruction).  At the locations in question,
there are no C++ objects in the current stack frame (and the JPEG and PNG
decoding libraries are C code).  Thus I don't believe there should be any
problem here.  A key design goal of C++ is making sure that well-formed C
programs still operate the same way, and thus it is certainly untrue that
any usage of setjmp() and longjmp() within an ostensibly-C++ program will
inherently cause crashes.

My understanding is that WebKit has been ported to Windows for three years.
> Can someone educate me on how current Chrome and Safari work on Windows? Why
> does such a basic problem exist but without being seen? Do they use the
> above image decoder files? I tried to run a program linked with a prebuilt
> Windows WebKit library and it crashes at setjmp() when accessing a jpeg
> file. Can this problem be fixed?


I have no idea what prebuilt Windows library you may have used or what kind
of crash you may have seen.  Chromium uses the above files on Windows
without issue (note that we compile with C++ exceptions disabled).   Brent
Fulgham's Cairo-based Windows port also uses these without problem.

PK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100427/e90c351f/attachment.html>