[issue9784] _msi.c warnings under 64-bit Windows
Jon Anglin jang...@fortresgrand.com added the comment: I have uploaded another patch that replaces CRT API calls with Win32 API calls. It compiles cleanly under 32 and 64 bit Windows. Is there a unit test for msilib? I was not able to find one, thus the patch is not fully tested. -- Added file: http://bugs.python.org/file19065/issue9784.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9784 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9784] _msi.c warnings under 64-bit Windows
Jon Anglin jang...@fortresgrand.com added the comment: I have the long-term plan to eliminate all CRT usage from Python on Windows. In this case, there is a straight-forward opportunity to do so. Oh, OK. If that is the plan then I am on board. I will re-code the patch using the Win32 API directly. It may interest you to know that _open calls CreateFile internally, I'm fully aware of that. I meant no disrespect, I just didn't know if you were a Windows guy. If you asked me what system call _open (or others) calls on Linux or Mac, I would have no clue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9784 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9783] _elementtree.c warnings under 64-bit Windows
Jon Anglin jang...@fortresgrand.com added the comment:
Martin is correct about this patch.
In cases where we really can't propagate Py_ssize_t to (e.g.
XML_Parse), we need to check for an int overflow, and raise
an exception if it does overflow.
Is this an appropriate approach?
int
PySize_AsInt(Py_ssize_t value)
{
if (value (Py_ssize_t)INT_MAX || value (Py_ssize_t)INT_MIN) {
PyErr_SetString(PyExc_OverflowError,
Size value can not be represented as an integer);
}
return (int)value;
}
I would only define this when sizeof(Py_ssize_t) sizeof(int) of course. In
other cases it would be a macro that just evaluates to value.
I would most likely need an unsigned version as well (although not for this
particular issue).
This code could be used in many C modules. Where in the Python code base should
such functions be placed?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9783
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9784] _msi.c warnings under 64-bit Windows
Jon Anglin jang...@fortresgrand.com added the comment: Martin Lowis do you mean API when you type SDK? If I understand what you are saying, you would rather use the Win32 API instead of the CRT API? It may interest you to know that _open calls CreateFile internally, _read calls ReadFile, _write calls WriteFile, _lseek calls SetFilePointer, and _close calls CloseHandle. There is a bit more to it than that but it is not really relevant to this discussion. What is relevant is that inside _open, CreateFile will return an OS HANDLE type (64 bits in our case) that is mapped to a 32 bit integer CRT file descriptor that is then returned. The other functions such as _read, etc…, will look up the 64 bit OS HANDLE value from the given 32 bit file descriptor and call the corresponding Win32 API function. We could rewrite the functions using the Win32 API directly but we don’t have to. I realize this is a Windows only module but the use of the CRT API is more familiar to a majority of the Python developers (I would guess). I stand by the patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9784 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9808] Implement os.getlogin on Windows
Changes by Jon Anglin jang...@fortresgrand.com: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9808 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9783] _elementtree.c warnings under 64-bit Windows
Jon Anglin jang...@fortresgrand.com added the comment: issue9783.diff provides a patch that will compile clean on 32 and 64 bit Windows systems. I tried to avoid explicit casts where I could, but it was not always possible. I have ported a lot of my company's code to 64 bit (all Windows based). In my experience many warnings are because of programmers using the int type in places where a size_t may be more appropriate. Most of the warnings here are due to mixing int and Py_ssize_t types. -- keywords: +patch Added file: http://bugs.python.org/file18988/issue9783.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9783 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9784] _msi.c warnings under 64-bit Windows
Jon Anglin jang...@fortresgrand.com added the comment: issue9784.diff contains a patch that compiles clean on 32 and 64 bit Windows. This patch is exactly what Amaury Forgeot d'Arc recommended in msg115750. -- keywords: +patch Added file: http://bugs.python.org/file18989/issue9784.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9784 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9808] Implement os.getlogin on Windows
Jon Anglin jang...@fortresgrand.com added the comment: The _countof(_x_) macro expands to something like this: sizeof(_x_)/sizeof(_x_[0]) This was an attempt by Microsoft to mitigate some buffer overrun issues. I have gotten in the habit of using it as it is less verbose. I have uploaded a new issue9808.diff file that removes the _countof macro. I will leave it up to those with commit privileges which version gets checked in. Personally I like it because it clarifies the programmers intent. Why not introduce it to the Python code base? -- Added file: http://bugs.python.org/file18912/issue9808.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9808 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9808] Implement os.getlogin on Windows
Jon Anglin jang...@fortresgrand.com added the comment: I went ahead and moved the test skip decorator to the class level as suggested by Brian Curtin, see issue9808-new.diff. -- Added file: http://bugs.python.org/file18886/issue9808-new.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9808 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9784] _msi.c warnings under 64-bit Windows
Changes by Jon Anglin jang...@fortresgrand.com: -- nosy: +janglin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9784 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9783] _elementtree.c warnings under 64-bit Windows
Changes by Jon Anglin jang...@fortresgrand.com: -- nosy: +janglin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9783 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9782] _multiprocessing.c warnings under 64-bit Windows
Changes by Jon Anglin jang...@fortresgrand.com: -- nosy: +janglin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9782 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9566] Compilation warnings under x64 Windows
Changes by Jon Anglin jang...@fortresgrand.com: -- nosy: +janglin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9566 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9614] _pickle is not entirely 64-bit safe
Changes by Jon Anglin jang...@fortresgrand.com: -- nosy: +janglin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9614 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9808] Implement os.getlogin on Windows
Jon Anglin jang...@fortresgrand.com added the comment: I can't answer that for the 'LOGNAME' environment variable on non-Windows systems, I was just keying off of what the docs claimed. As for Windows, I just came across this article http://support.microsoft.com/kb/273633 that shows we can not rely on this in the test. I only put those environment variables in the test because I thought this test was a little weak (what else can we do?) user_name = os.getlogin() self.assertNotEqual(0, len(user_name)) Even though %USERNAME% == os.getlogin() MOST of the time. It should be removed from the test. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9808 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9808] Implement os.getlogin on Windows
Jon Anglin jang...@fortresgrand.com added the comment: Here is an updated patch with the updated test. This test does not use either the LOGNAME or USERNAME environment variables. -- Added file: http://bugs.python.org/file18814/issue9808.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9808 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9752] MSVC Compiler warning in Python\import.c
Jon Anglin jang...@fortresgrand.com added the comment: Visual Studio ships with the source code for the CRT (\Program Files\Microsoft Visual Studio 9.0\VC\crt\src). I looked up _mkdir. It does just call CreateDirectory(path, NULL). If no error occurs it returns zero. If an error occurs, it then converts the result of GetLastError to an appropriate errno code and returns -1. Thus the following calls are equivalent: _mkdir(dirname); CreateDirectory(dirname, NULL); -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9752 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9752] MSVC Compiler warning in Python\import.c
Jon Anglin jang...@fortresgrand.com added the comment: How about this: see no-macro.diff BTW: should I be using the .patch extension or .diff extension? -- Added file: http://bugs.python.org/file18798/no-macro.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9752 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9808] Implement os.getlogin on Windows
New submission from Jon Anglin jang...@fortresgrand.com: This is a feature request to implement the os.getlogin function on Windows systems. This may not be a widely used function, but implementing on Windows will bring Python on Windows one step closer to Python on Unix (like) systems. The os_getlogin.diff file contains my proposed patch to add this functionality for Windows. -- components: Library (Lib), Windows files: os_getlogin.diff keywords: patch messages: 115927 nosy: janglin priority: normal severity: normal status: open title: Implement os.getlogin on Windows type: feature request versions: Python 3.2 Added file: http://bugs.python.org/file18808/os_getlogin.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9808 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6394] getppid support in os module on Windows
Jon Anglin jang...@fortresgrand.com added the comment: Here is a unit test for os.getppid on Windows. The test_os.diff file is the diff of the Lib/test/test.os.py file from the py3k svn branch. -- Added file: http://bugs.python.org/file18784/test_os.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6394 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6394] getppid support in os module on Windows
Jon Anglin jang...@fortresgrand.com added the comment: I have uploaded a new diff file (from the py3k svn trunk) that has all of the changes in Doc/library/os.rst, Modules/posixmodule.c, and Lib/test/test_os.py. It is called 6394.diff. Let me know if I can do anything else to make this happen. -- Added file: http://bugs.python.org/file18785/6394.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6394 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9752] MSVC Compiler warning in Python\import.c
Jon Anglin jang...@fortresgrand.com added the comment: Windows provides two versions of mkdir in direct.h: int mkdir(const char* dirname) int _mkdir(const char* dirname) The latter is the preferred function because it is conformant to the ISO C++ standard. As you can see, neither function has a mode parameter like the Unix system call. The directory permissions are inherited from the parent directory. I simply defined a macro that expands to the correct version of mkdir for the system that Python is being compiled upon. I found other instances in the Python source where similar things were done so I hope my solution is acceptable. I have tested my solution on 32 and 64 bit builds of Python from the py3k svn trunk. -- keywords: +patch nosy: +janglin Added file: http://bugs.python.org/file18792/9752.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9752 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6394] getppid support in os module on Windows
Jon Anglin jang...@fortresgrand.com added the comment: Just some information, on Windows: - process ids are re-used. - parent process id is set at process creation time and never updated. (Windows Internal 4th Ed. by Russinovich and Solomon). Thus, I would say that a long running process can not rely on the value of its parent process id. The parent may not be running, or the process id may have been re-used and the process with that id may not be in fact the actual parent. Having said that, I don't know the algorithm that Windows uses for process ids, so collisions may be rare (or not). -Do these same issues exist on Unix systems? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6394 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6394] getppid support in os module on Windows
Jon Anglin jang...@fortresgrand.com added the comment: I didn't raise an exception because the Unix version never fails (or raises) so I thought to maintain compatibility I would always return a value. Do you advise that I should change it? As for the tabs... This entire process is new to me and I am learning, it was just a mistake. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6394 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6394] getppid support in os module on Windows
New submission from Jon Anglin jang...@fortresgrand.com: Implements getppid in the os module on Windows systems. The getppid function was only available on Unix like systems, this diff patch brings this functionality to Windows systems. This function will return the parent process Id, upon error it will return -1. This differs from the Unix implementation that never fails. Due to the way Windows returns the parent process Id, a never fail guarantee can not be made. It should only fail in low memory conditions. This patch is on the latest svn trunk ( http://svn.python.org/projects/python/trunk). This implementation should port to any python version (older or newer). I have personally tested it against Python 2.5.4, 2.6.2, 3.1, and the aforementioned svn trunk. -- components: Library (Lib) files: mydiffs.diff keywords: patch messages: 89981 nosy: janglin severity: normal status: open title: getppid support in os module on Windows type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file14419/mydiffs.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6394 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6394] getppid support in os module on Windows
Jon Anglin jang...@fortresgrand.com added the comment: Implements getppid in the os module on Windows systems. The getppid function was only available on Unix like systems, this diff patch brings this functionality to Windows systems. This function will return the parent process Id, upon error it raises a WindowsError. This differs from the Unix implementation that never fails. Due to the way Windows returns the parent process Id, a never fail guarantee can not be made. This is a revision of a previous post. The file Issue6394-1.diff contains the updated patches. -- Added file: http://bugs.python.org/file14421/Issue6394-1.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6394 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
