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 [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
