FormatError() in callproc.c under win32
Hi! 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? Is it just to check if the errorcode is registered in the stringtables? The reason I ask is the CE port. The FormatMessage API exists there (or, rather, the FormatMessageW API), but the tables containing the error messages are optional for the OS and for space reasons many vendors chose not to include them. That means that the function there regularly fails to retrieve the requested string. My first approach was to fall back to simply providing a sting with a numeric representation of the errorcode, but that would change the meaning of above function, because then it could never fails. My second approach was to enhance PyErr_SetFromWindowsErr() to handle the additional error codes that are checked in SetException(). However, those require more context than just the error code, they use the EXCEPTION_RECORD passed to SetException() for that. My third approach would be to filter out the special error codes first and delegate all others to PyErr_SetFromWindowsErr(). The latter already handles the lack of a string for the code by formatting it numerically. This would also improve consistency, since the two functions use different ways to format unrecognised errors numerically. This approach would change where and how a completely unrecognised error code is formatted, but would otherwise be pretty equivalent. Suggestions? Uli -- Sator Laser GmbH Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 ************************************************************************************** Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 ************************************************************************************** Visit our website at <http://www.satorlaser.de/> ************************************************************************************** Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden. E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich. **************************************************************************************
Ulrich Eckhardt schrieb:
Hi!
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? Is it just to check if the errorcode is registered in the stringtables?
I think that your guess is somewhat similar to what I thought when I wrote the code.
The reason I ask is the CE port. The FormatMessage API exists there (or, rather, the FormatMessageW API), but the tables containing the error messages are optional for the OS and for space reasons many vendors chose not to include them. That means that the function there regularly fails to retrieve the requested string.
My first approach was to fall back to simply providing a sting with a numeric representation of the errorcode, but that would change the meaning of above function, because then it could never fails.
My second approach was to enhance PyErr_SetFromWindowsErr() to handle the additional error codes that are checked in SetException(). However, those require more context than just the error code, they use the EXCEPTION_RECORD passed to SetException() for that.
My third approach would be to filter out the special error codes first and delegate all others to PyErr_SetFromWindowsErr(). The latter already handles the lack of a string for the code by formatting it numerically. This would also improve consistency, since the two functions use different ways to format unrecognised errors numerically. This approach would change where and how a completely unrecognised error code is formatted, but would otherwise be pretty equivalent.
The third approach is fine with me. Sidenote: The only error codes that I remember having seen in practice are 'access violation reading...' and 'access violation writing...', although it may be that on WinCE 'datatype misalignment' may also be possible. -- Thanks, Thomas
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?
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. Regards, Martin
On Monday 26 January 2009, Thomas Heller wrote:
Ulrich Eckhardt schrieb:
In callproc.c from trunk is a function called SetException(), which calls [...] My third approach would be to filter out the special error codes first and delegate all others to PyErr_SetFromWindowsErr(). The latter already handles the lack of a string for the code by formatting it numerically. This would also improve consistency, since the two functions use different ways to format unrecognised errors numerically. This approach would change where and how a completely unrecognised error code is formatted, but would otherwise be pretty equivalent.
The third approach is fine with me. Sidenote: The only error codes that I remember having seen in practice are 'access violation reading...' and 'access violation writing...', although it may be that on WinCE 'datatype misalignment' may also be possible.
Submitted as patch for issue #5078. Note: under CE, you can actually encounter datatype misalignments, since it runs on CPUs that don't emulate them. I wonder if the same doesn't also apply to win64.... Uli -- Sator Laser GmbH Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 ************************************************************************************** Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 ************************************************************************************** Visit our website at <http://www.satorlaser.de/> ************************************************************************************** Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden. E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich. **************************************************************************************
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?
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
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. 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. In any case, CCing Luke on the issue, maybe he can clarify things. cheers Uli ************************************************************************************** Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 ************************************************************************************** Visit our website at <http://www.satorlaser.de/> ************************************************************************************** Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden. E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich. **************************************************************************************
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
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
Note: under CE, you can actually encounter datatype misalignments, since it runs on CPUs that don't emulate them. I wonder if the same doesn't also apply to win64....
I don't think you can get misalignment traps on AMD64. Not sure about IA-64: I know that the processor will trap on misaligned accesses, but the operating system might silently fix the access. Regards, Martin
participants (4)
-
"Martin v. Löwis" -
Luke Dunstan -
Thomas Heller -
Ulrich Eckhardt