> Here's a patch against today's snapshot of head. > >>> I think that you has to compile with -DWIN32_LEAN_AND_MEAN in >>> Configure before to do some undefs in openssl headers. > > I'm not really convinced, but for the time being, I've added that > compile > option to get rid of that more or less cosmetic issue. > Apart from adding a line to configure, I needed a slight modification > to apps/speed.c and engines/e_aep.c because mingw-w64 comes > with definitions for "pid_t" and "alarm"
How do we know that these are not or should not be treated as mingw64 bugs? I mean it worked for mingw for years (I wonder how by the way), now ancestor is *being developed* and how come it's not its fault:-) Well, I can accept that pid_t could be treated better in OpenSSL (#ifdef there is nothing but strange), but I don't buy masking of alarm. It's impossible to implement Unix-ish alarm on Windows and it simply shouldn't be there (nor SIGALRM definition). Quick check reveals that alarm is nothing but "return 0." What's more appropriate: to be honest or not to tell truth? I mean absence of alarm would be honest, while implementing it as return 0 would be "not telling truth"... > and in crypto/mem_cmp.c, http://cvs.openssl.org/chngview?cn=17337. A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
