> From: eckhardt@satorlaser.com
> To: python-dev@python.org
> Subject: Re: [Python-Dev] FormatError() in callproc.c under win32
> Date: Tue, 27 Jan 2009 12:16:01 +0100
> CC: coder_infidel@hotmail.com
>
> On Monday 26 January 2009, Martin v. Löwis wrote:
> > > In callproc.c from trunk is a function called SetException(), which calls
> > > FormatError() only to discard the contents. Can anyone enlighten me to
> > > the reasons thereof?

The left over call to FormatError() looks like a mistake to me.

> >
> > Interestingly enough, the code used to say
> >
> > PyErr_SetString(PyExc_WindowsError, lpMsgBuf);
> >
> > Then it was changed to its current form, with a log message of
> >
> > Changes for windows CE, contributed by Luke Dunstan. Thanks a lot!
> >
> > See
> >
> >
> http://ctypes.cvs.sourceforge.net/viewvc/ctypes/ctypes/source/callproc.c?hideattic=0&r1=1.127.2.15&r2=1.127.2.16
> >
> > I suggest you ask Thomas Heller and Luke Dunstan (if available) what the
> > rationale for this partial change was.
>
> I can only guess:
> 1. Those changes seem to generate TCHAR strings. This is necessary to compile
> it on both win9x (TCHAR=char) and CE (TCHAR=wchar_t). Since win9x was dropped
> from the supported platforms, that isn't necessary any more and all the code
> could use WCHAR directly.

As far as I remember TCHAR was char for Windows NT/2K/XP Python builds too, at least at that time, but yes it would be clearer to use WCHAR instead now.

> 2. Those changes also seem to change a few byte-strings to Unicode-strings,
> see format_error(). This is a questionable step, since those are changes that
> are visible to Python code. Worse, even on the same platform it could return
> different string types when the lookup of the errorcode fails. I wonder if
> that is intentional.

Probably not intentional. Yes, it would be better if the return value was either always char or always WCHAR.

>
> In any case, CCing Luke on the issue, maybe he can clarify things.
>
> cheers
>
> Uli

Good luck,
Luke