[gdal-dev] Windows MSVC exception handling model

[Even Rouault]

On mardi 14 novembre 2017 20:04:18 CET Lucian Plesea wrote:
> Is there a specific reason to use /EHsc and not /EHs for windows
> compilation?The difference is that /EHsc, which is used now, tells the MSVC
> that extern "C" functions can't throw exceptions. I am trying to use
> libjpeg and use C++ exception instead of setjmp/longjmp, by having libjpeg
> call a C++ function that throws an exception.  With /EHs it works fine, but
> with /EHsc, incorrect code will be generated and the exception will not be
> caught. Thanks,

My digging of history:

*/GX flag introduced per
https://github.com/OSGeo/gdal/commit/08015d0aed3fdab22c9048ed45d017faa4b43cdf

* modified to /EHsc per
https://github.com/OSGeo/gdal/commit/6fea01f333617751c4086a354e53836cb70f3cab
https://trac.osgeo.org/gdal/ticket/1083

I'd believe /EHsc might theoretically generate better code than /EHs since no code for
exception catching is needed when calling extern C functions

But I'd be concerned that with gcc throwing C++ exceptions from symbols with C linkage
would be undefined behaviour, as the following thread would seem to suggest:

https://stackoverflow.com/questions/15845681/can-c-functions-marked-as-extern-c-throw

Apparently gcc -fexceptions might help
       -fexceptions
           Enable exception handling.  Generates extra code needed to propagate exceptions.  For some targets, this implies GCC generates frame unwind information for all functions, which can produce
           significant data size overhead, although it does not affect execution.  If you do not specify this option, GCC enables it by default for languages like C++ that normally require exception
           handling, and disables it for languages like C that do not normally require it.  However, you may need to enable this option when compiling C code that needs to interoperate properly with
           exception handlers written in C++.  You may also wish to disable this option if you are compiling older C++ programs that don't use exception handling.

But what about other compilers, etc.

So it would seem safer to me avoiding throwing C++ exception from libjpeg callbacks.

But I'm aware that setjmp/longjmp in C++ code is also tricky to do correctly. The safer is to create
small wrappers for each C function that can cause longjmp() to be called, and make sure no
C++ object is used in the wrapper itself.

like the following used in the png driver:

static bool safe_png_read_image(png_structp hPNG,
                                png_bytep *png_rows,
                                jmp_buf     sSetJmpContext)
{
    if( setjmp( sSetJmpContext ) != 0 )
        return false;
    png_read_image( hPNG, png_rows );
    return true;
}


Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20171114/5718d7c1/attachment.html>