[Python-Dev] Who understands _ssl.c on Windows? (original) (raw)
"Martin v. Löwis" martin at v.loewis.de
Sat Apr 8 11:38:14 CEST 2006
- Previous message: [Python-Dev] Who understands _ssl.c on Windows?
- Next message: [Python-Dev] Who understands _ssl.c on Windows?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] Who understands _ssl.c on Windows?
- Next message: [Python-Dev] Who understands _ssl.c on Windows?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]