Jon Anglin 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
Jon Anglin 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_As
Jon Anglin 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.
Jon Anglin 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
Jon Anglin 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
Jon Anglin 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 exper
Changes by Jon Anglin :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue9808>
___
___
Python-bugs-list mailing list
Unsubscri
Jon Anglin 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
Jon Anglin 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
<h
Changes by Jon Anglin :
--
nosy: +janglin
___
Python tracker
<http://bugs.python.org/issue9614>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Jon Anglin :
--
nosy: +janglin
___
Python tracker
<http://bugs.python.org/issue9566>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Jon Anglin :
--
nosy: +janglin
___
Python tracker
<http://bugs.python.org/issue9782>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Jon Anglin :
--
nosy: +janglin
___
Python tracker
<http://bugs.python.org/issue9783>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Jon Anglin :
--
nosy: +janglin
___
Python tracker
<http://bugs.python.org/issue9784>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jon Anglin 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
<h
Jon Anglin 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
New submission from Jon Anglin :
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
Jon Anglin 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
<http://bugs.python.org/issue9
Jon Anglin 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
Jon Anglin 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
Jon Anglin 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
Jon Anglin 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
Jon Anglin 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
Jon Anglin added the comment:
I have addressed the issues brought up by Amaury Forgeot d'Arc except
for the unit test. I will get a unit test in tommorrow. Thank you for
the feedback. I have uploaded a new diff file Issue6394-2.diff.
- Should I remove the old diff files?
I ran some
Jon Anglin 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
New submission from Jon Anglin :
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
Jon Anglin 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 learnin
27 matches
Mail list logo
