I ran my typo.pl perl script that locates possible C/C++ typos.

I found four that looked valid.

Two of the typos were in the Python directory {pythonrun.c, 
dynload_win.c}, two were in PC/bdist_wininst {install.c, extract.c}.

Python/dynload_win.c:
Win32 API FormatMessageW() expects the 6th parameter to be the count of 
characters, NOT the count of bytes.

Python/pythonrun.c:
The source code contains "if (ferr != NULL || ferr != Py_None)". This 
does not work as expected - if ferr == NULL, then the second part of 
the if expression will succeed. Look at the code handling fout about 8 
lines up to see the correct code.

PC/bdist_wininst/extract.c:
Win32 API CreateFileMapping returns NULL on error, not 
INVALID_HANDLE_VALUE.

PC/bdist_wininst/install.c:
Win32 API CreateFileMapping returns NULL on error, not 
INVALID_HANDLE_VALUE.

I don't know Windows APIs but the pythonrun.c bug is genuine.

Here are the URLs to the MSDN documentation for CreateFileMapping and 
FormatMessage[A|W]:
<http://msdn.microsoft.com/en-us/library/aa366537.aspx>
<http://msdn.microsoft.com/en-us/library/ms679351.aspx>

For CreateFileMapping(), from the Return Value section:
"If the function fails, the return value is NULL. To get extended error 
information, call GetLastError."

For FormatMessage[A|W]:
nSize [in] 
If the FORMAT_MESSAGE_ALLOCATE_BUFFER flag is not set, this parameter 
specifies the size of the output buffer, in TCHARs.

For the dynload_win.c typo, it's technically a possible buffer 
overflow, but you'd need to find an error that had an error message 
that's longer than 259 chars.

In pythonrun.c, the if statements for fout and ferr and almost 
identical. Probably a good idea to convert the if-statement to a 
separate function and call that function with fout and then ferr.

It looks to me as though all these are valid, and the patch should be 
applied to py3k and the 3.0 maintenance branch.

Minor nit: the "sizeof(theInfo)" line exceeds 79 characters, in violation 
of PEP 7.

Is there any core developer who's in a position to test this patch on 
Windows?

It's difficult to really test such errors.

Moreover, on the top of the bdist_wininst files, a comment says loudly:  
IF CHANGES TO THIS FILE ARE CHECKED INTO PYTHON CVS, THE RECOMPILED 
BINARIES MUST BE CHECKED IN AS WELL!

attached modified diff patch so line length <=79 chars

> It's difficult to really test such errors.

When I can't control the called function, I usually step through the 
code in a debugger and change the result variable in question to the 
appropriate value to see if the code handles failed function calls 
correctly. 

In the three Win32 API cases, it's clear that the failure path was not 
tested.

And I can't see how the ferr if statement was tested with a failure 
value either.

I fixed the typo in pythonrun.c: r81156. I don't use Windows, so I cannot review the other fixes.

I don't run Windows either but I believe sizeof(char) == 1 is guaranteed by the C standard, so the first report (Python/dynload_win.c) is invalid.

The last two appear to be valid [1], and a common mistake. [2]  Unit tests are needed for these.  I also notice that r81156 does not add a unit test either.  ISTM, a test case can be crafted by setting sys.stderr to None.

[1] http://msdn.microsoft.com/en-us/library/aa366537(VS.85).aspx
[2] http://blogs.msdn.com/b/oldnewthing/archive/2004/03/02/82639.aspx

Strike my comment about Python/dynload_win.c - I was looking at the trunk version instead of py3k.  In py3k theInfo is wchar_t and patch seems to be valid.

Martin would be the expert for bdist_wininst.

New changeset 4db1b0bb3683 by Gregory P. Smith in branch '3.3':
Fixes issue4653 - Correctly specify the buffer size to FormatMessageW and
http://hg.python.org/cpython/rev/4db1b0bb3683

New changeset ace52be8da89 by Gregory P. Smith in branch 'default':
Fixes issue4653 - Correctly specify the buffer size to FormatMessageW and
http://hg.python.org/cpython/rev/ace52be8da89

the pythonrun issue had already been fixed.  the others were still there (valid bugs, but were unlikely to be causing problems given the codepaths).  fixed.

I didn't write a Misc/NEWS entry on the commit because I didn't know how to usefully describe these minor fixes.  someone else is welcome to contribute one if they feel the need.