[gdal-dev] Windows MSVC exception handling model

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] Windows MSVC exception handling model

Lucian Plesea-2
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,

Lucian

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Windows MSVC exception handling model

Even Rouault-2

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


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev