#88 win32event.MsgWaitForMultipleObjectsEx() segfaults

[Ziga Seilnacht]

win32event.MsgWaitForMultipleObjectsEx() segfaults if
you call it with an empty list of handles (I didn't try
calling with non-empty list).
The docs say that this should be possible, see:
http://blogs.msdn.com/oldnewthing/archive/2006/01/25/517395.aspx
(OK, it's not exactly documentation :)

The problem lies in dynamic loading of said function.
Since the win32event module already requires Windows XP,
(#define _WIN32_WINNT 0x0501), and this function was
added in Windows NT 4.0, I simply removed the dynamic
loading.

The patch also contains a very basic test.

[Ziga Seilnacht]

[Ziga Seilnacht]

Updated patch

[Ziga Seilnacht]

Ok, the old version segfaults even if you have nonempty list:

>>> import win32event
>>> event = win32event.CreateEvent(None, 0, 0, None)
>>> res = win32event.MsgWaitForMultipleObjectsEx([event], 0, 0, 0, 0) -> segfault

This is on Windows XP SP3. Since it looks that this function was
never usable, I attach a new patch that also changes its interface.

The native MsgWaitForMultipleObjectsEx() function doesn't have a
fWaitAll parameter, but the Python wrapper did have it and never did
anything with it. So this updated patch simply removes it.
File Added: MsgWaitForMultipleObjectsEx2.diff

[Ziga Seilnacht]

Of course, I forgot to update the test in the second version of
the patch... Here is the third, and hopefully last version.
File Added: MsgWaitForMultipleObjectsEx3.diff

[Ziga Seilnacht]

updated patch with fixed test

[Mark Hammond]

Thanks - I checked the changes in:
Checking in src/win32event.i;
new revision: 1.10; previous revision: 1.9
Checking in test/test_win32event.py;
new revision: 1.2; previous revision: 1.1

I'm guessing the lack of a calling convention on the function pointer was the problem.

FYI, the _WIN32_WINNT macro isn't reliable in this context - often we use a higher version to get the structure definitions, but still take care to dynamically load the function pointers that don't exist in all versions we support. In this case though you are correct - the function is now available in all versions we support, so I just nuked the dynamic load code too rather than verifying it was the calling convention.

Thanks!