[Python-Dev] Who understands _ssl.c on Windows?

["Martin v. Löwis"]

Tim Peters wrote:
> _Perhaps_ it's the case that doubles are aligned to an 8-byte boundary
> when socketmodule.c is compiled, but (for some unknown reason) only to
> a 4-byte boundary when _ssl.c is compiled.

This is indeed what happens, because of what I consider three bugs:
one in Python, and two in the Platform SDK:
- _ssl.mak fails to define WIN32; this is bug 1
- because of that, WinSock2.h includes pshpack4.h at the beginning
  (please take a look at the comment above that include)
- WinSock2.h includes windows.h (and some other stuff). This
  ultimately *defines* WIN32. I haven't traced where exactly it
  gets defined, but verified that it does before the end of
  WinSock2.h. Most likely, it comes from Ole2.h. This is bug 2:
  if WIN32 is a flag to the SDK headers, they shouldn't set it
  themselves. If they want to assume it is always defined, they
  should just make the things that it currently affects
  unconditional.
- WinSock2 then includes poppack.h, under the same condition
  (WIN32 not defined) as pshpack4.h. This is bug 3: the code
  assumes that the condition doesn't change, but it might.
  They should instead set a macro (say, WINSOCK2_PSHPACK4)
  at push time, and then check for it to determine if they
  need to pop.

Anyway, the fix is then straight-forward: just add /DWIN32 to _ssl.mak.

Regards,
Martin