Sorry for late reply; been under the weather lately, healthwise, so this is my first 'on-line' experience in a while ;-)
As far as the brain is operational again... I'd say the quickest way to fix this is to wrap the __try/__except chunk in a compiler-specific preproc check a la: #if defined(_MSC_VER) __try ... __except ... #endif No use doing #else branches for that one, as the alternatives are: - 'try/catch' without the underscores is (a) C++ and (b) does not catch hardware exceptions like __try/__except/... does (except, yes, here we have those nutters again, in MSVC compilers before MSVC2005; see also http://www.thunderguy.com/semicolon/2002/08/15/visual-c-exception-handling/ ), plus: - I don't think mingw et al have something equivalent to offer anyhow, unless they've come up with some harebrained signal/sigaction scheme of their own instead. Allow me to cringe if they have. - The choice to 'roll your own' I would strongly advise to stay the hell away from; for a hint of what it might take for starters, see http://www.microsoft.com/msj/0197/Exception/Exception.aspx So unless someone can teach me the error of my current ways regarding SEH and gcc on Win32/64, I'd say that __try/__except encased section should be available for MSVC compilers only (or more precise: compilers which support Win32/64 hardware exception handling through __try/__except compiler support). Anybody else should not be executing the enclosed code section. The excuse here is that it's only one of multiple parts collecting randomness input for the OpenSSL SPRNG; mingw/etc. builds may be thought to be 'slightly less desirable' this way, but the counterpoint is a real (if minor?) risk of hardware failures resulting in unpredictable application termination for those compiler environments on Win32/Win64. After all, the whole point, IIRC, of adding those __try/__except lines in there was it being the only viable run-time fix for reported run-time instability of the system calls in the enclosed section, so if we remove them, it's open season for program abort again. So far, my thoughts on the matter. Steve, what do you think? I take it you'd like an updated patch/diff file to go with this, right? Anyhow, I'll investigate the matter in more depth when I'm feeling capable again in a couple of days. Right now, I've still got too many fluid leaks from too many holes. And since the small print on this here pillbox says the intake of brain coolant is empathetically prohibited, I'd really like to run my think tank in low gear for a little while, if you'll allow me. ;-) On Sun, Sep 20, 2009 at 2:39 PM, Stephen Henson via RT <r...@openssl.org> wrote: >> [steve - Fri Jul 24 16:01:44 2009]: >> >> Patch now applied. Thanks for the report. >> > > Update. This doesn't work on non-VC++ Windows builds e.g. mingw. The > __try+__except stuff chokes them. For now reverting to old code for > those cases. Any suggestions for an equivalent fix on those? > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > > -- Met vriendelijke groeten / Best regards, Ger Hobbelt -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 -------------------------------------------------- ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
