[issue1039] Asssertion in Windows debug build
New submission from Thomas Heller:
In a windows debug build, an assertion is triggered when os.execvpe is
called with an empty argument list:
self.assertRaises(OSError, os.execvpe, 'no such app-', [], None)
The same problem is present in the trunk version.
Attached is a patch that fixes this, with a test.
--
components: Windows
files: os.diff
messages: 55350
nosy: theller
severity: normal
status: open
title: Asssertion in Windows debug build
type: crash
versions: Python 3.0
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1039>
__Index: Lib/test/test_os.py
===
--- Lib/test/test_os.py (revision 57596)
+++ Lib/test/test_os.py (working copy)
@@ -441,6 +441,9 @@
def test_execvpe_with_bad_program(self):
self.assertRaises(OSError, os.execvpe, 'no such app-', [], None)
+def test_execvpe_with_bad_arglist(self):
+self.assertRaises(ValueError, os.execvpe, 'notepad', [], None)
+
class Win32ErrorTests(unittest.TestCase):
def test_rename(self):
self.assertRaises(WindowsError, os.rename, test_support.TESTFN, test_support.TESTFN+".bak")
Index: Modules/posixmodule.c
===
--- Modules/posixmodule.c (revision 57596)
+++ Modules/posixmodule.c (working copy)
@@ -2834,6 +2834,11 @@
PyMem_Free(path);
return NULL;
}
+ if (argc < 1) {
+ PyErr_SetString(PyExc_ValueError, "execv() arg 2 must not be empty");
+PyMem_Free(path);
+ return NULL;
+ }
argvlist = PyMem_NEW(char *, argc+1);
if (argvlist == NULL) {
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1043] test_builtin failure on Windows
New submission from Thomas Heller: test test_builtin failed -- Traceback (most recent call last): File "c:\svn\py3k\lib\test\test_builtin.py", line 1473, in test_round self.assertEqual(round(1e20), 1e20) AssertionError: 0 != 1e+020 -- components: Windows messages: 55355 nosy: theller severity: normal status: open title: test_builtin failure on Windows versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1043> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1042] test_glob fails with UnicodeDecodeError
New submission from Thomas Heller:
Unicode errors in various tests - not only in test_glob:
test_glob
test test_glob failed -- Traceback (most recent call last):
File "c:\svn\py3k\lib\test\test_glob.py", line 87, in
test_glob_directory_names
eq(self.glob('*', '*a'), [])
File "c:\svn\py3k\lib\test\test_glob.py", line 41, in glob
res = glob.glob(p)
File "c:\svn\py3k\lib\glob.py", line 16, in glob
return list(iglob(pathname))
File "c:\svn\py3k\lib\glob.py", line 42, in iglob
for name in glob_in_dir(dirname, basename):
File "c:\svn\py3k\lib\glob.py", line 56, in glob1
names = os.listdir(dirname)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 27-31:
unexpected end of data
--
components: Windows
messages: 55354
nosy: theller
severity: normal
status: open
title: test_glob fails with UnicodeDecodeError
versions: Python 3.0
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1042>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040] Unicode problem with TZ
Thomas Heller added the comment: BTW, setting the environment variable TZ to, say, 'GMT' makes the problem go away. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1040> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040] Unicode problem with TZ
New submission from Thomas Heller:
In my german version of winXP SP2, python3 cannot import the time module:
c:\svn\py3k\PCbuild>python_d
Python 3.0x (py3k:57600M, Aug 28 2007, 07:58:23) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
Traceback (most recent call last):
File "", line 1, in
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 9-11:
invalid data
[36719 refs]
>>> ^Z
The problem is that the libc '_tzname' variable contains umlauts. For
comparison, here is what Python2.5 does:
c:\svn\py3k\PCbuild>\python25\python
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.tzname
('Westeurop\xe4ische Normalzeit', 'Westeurop\xe4ische Normalzeit')
>>>
--
components: Windows
messages: 55351
nosy: theller
severity: normal
status: open
title: Unicode problem with TZ
versions: Python 3.0
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1040>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1041] io.py problems on Windows
New submission from Thomas Heller: Running the PCBuild\rt.bat script fails when it compares the expected output with the actual output. Some inspection shows that the comparison fails because there are '\n' linefeeds in the expected and '\n\r' linefeeds in the actual output: c:\svn\py3k\PCbuild>python_d -E -tt ../lib/test/regrtest.py test_grammar test test_grammar produced unexpected output: ** *** mismatch between line 1 of expected output and line 1 of actual output: - test_grammar + test_grammar ? + (['test_grammar\n'], ['test_grammar\r\n']) ... and so on ... (The last line is printed by some code I added to Lib\regrtest.py.) It seems that this behaviour was introduced by r57186: New I/O code from Tony Lownds implement newline feature correctly, and implements .newlines attribute in a 2.x-compatible fashion. The patch at http://bugs.python.org/issue1029 apparently fixes this problem. -- components: Windows messages: 55353 nosy: theller severity: normal status: open title: io.py problems on Windows versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1041> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040] Unicode problem with TZ
Thomas Heller added the comment: IMO the very best would be to avoid as many conversions as possible by using the wide apis on Windows. Not for _tzname maybe, but for env vars, sys.argv, sys.path, and so on. Not that I would have time to work on that... __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1040> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1039] Asssertion in Windows debug build
Thomas Heller added the comment: Applied in rev. 57731. -- resolution: accepted -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1039> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1617699] slice-object support for ctypes Pointer/Array
Thomas Heller added the comment: Set to accepted. As pointed out in private email, please apply it to the trunk. Your thoughts about the 'length' of pointers make sense, and are very similar to what I had in mind when I implemented pointer indexing. For indexing pointers, negative indices (in the C sense, not the usual Python sense) absolutely are needed, IMO. For slicing, missing indices do not really have a meaning - would it be possible to disallow them? -- resolution: -> accepted _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1617699> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1617699] slice-object support for ctypes Pointer/Array
Changes by Thomas Heller: -- assignee: theller -> twouters _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1617699> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1617699] slice-object support for ctypes Pointer/Array
Thomas Heller added the comment: Yes. But looking at your examples I think it would be better to forbid missing indices completely instead of allowing them only where they clearly mean 0. Writing (and reading!) a 0 is faster than thinking about if a missing index is allowed or what it means. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1617699> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1777530] ctypes on Solaris
Thomas Heller added the comment:
This is an experimental patch (solaris.patch). Can you please proofread
it and try it out on the solaris machine?
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1777530>
_Index: util.py
===
--- util.py (revision 57552)
+++ util.py (working copy)
@@ -70,11 +70,18 @@
# assuming GNU binutils / ELF
if not f:
return None
-cmd = "objdump -p -j .dynamic 2>/dev/null " + f
-res = re.search(r'\sSONAME\s+([^\s]+)', os.popen(cmd).read())
-if not res:
-return None
-return res.group(1)
+if sys.platform.startswith("solaris"):
+cmd = "elfdump -d 2>/dev/null " + f
+res = re.search(r'\sSONAME\s+([^\s]+)\s+([^\s]+)', os.popen(cmd).read())
+if not res:
+return None
+return res.group(2)
+else:
+cmd = "objdump -p -j .dynamic 2>/dev/null " + f
+res = re.search(r'\sSONAME\s+([^\s]+)', os.popen(cmd).read())
+if not res:
+return None
+return res.group(1)
if (sys.platform.startswith("freebsd")
or sys.platform.startswith("openbsd")
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1777530] ctypes on Solaris
Thomas Heller added the comment:
Martin, here is a patch (solaris-2.patch), hopefully according to your
comments.
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1777530>
_Index: util.py
===
--- util.py (revision 57929)
+++ util.py (working copy)
@@ -66,16 +66,28 @@
return None
return res.group(0)
-def _get_soname(f):
-# assuming GNU binutils / ELF
-if not f:
-return None
-cmd = "objdump -p -j .dynamic 2>/dev/null " + f
-res = re.search(r'\sSONAME\s+([^\s]+)', os.popen(cmd).read())
-if not res:
-return None
-return res.group(1)
+if sys.platform == "sunos5":
+# use /usr/ccs/bin/dump on solaris
+def _get_soname(f):
+if not f:
+return None
+cmd = "/usr/ccs/bin/dump -Lpv 2>/dev/null " + f
+res = re.search(r'\[.*\]\sSONAME\s+([^\s]+)', os.popen(cmd).read())
+if not res:
+return None
+return res.group(1)
+else:
+def _get_soname(f):
+# assuming GNU binutils / ELF
+if not f:
+return None
+cmd = "objdump -p -j .dynamic 2>/dev/null " + f
+res = re.search(r'\sSONAME\s+([^\s]+)', os.popen(cmd).read())
+if not res:
+return None
+return res.group(1)
+
if (sys.platform.startswith("freebsd")
or sys.platform.startswith("openbsd")
or sys.platform.startswith("dragonfly")):
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1777530] ctypes on Solaris
Thomas Heller added the comment: Can someone please test the patch and report back? -- Thanks _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1777530> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1777530] ctypes on Solaris
Thomas Heller added the comment: Fixed in SVN: trunk rev 58155, release25-maint rev 58158. Thanks. -- resolution: -> fixed status: open -> closed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1777530> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1203] ctypes doesn't work on Mac with --disable-toolbox-glue
Thomas Heller added the comment:
Would you like to prepare a patch? I have no idea how the return values
of gestalt.gestalt("sysv") and platform.release() relate to each other...
--
nosy: +theller
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1203>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1203] ctypes doesn't work on Mac with --disable-toolbox-glue
Thomas Heller added the comment:
On the mac where I have access to platform.release() returns the string
'8.10.0'. gestalt.gestalt("sysv") returns 0x1049. Your patch does not
look correct to me.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1203>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1203] ctypes doesn't work on Mac with --disable-toolbox-glue
Thomas Heller added the comment:
This patch looks better. However, the 'os.uname()' function seems to
return the information that we need; so I updated the patch to use this
instead. Can you please proofread it (osx.patch) ?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1203>
__Index: Lib/ctypes/__init__.py
===
--- Lib/ctypes/__init__.py (revision 58034)
+++ Lib/ctypes/__init__.py (working copy)
@@ -24,0 +24,0 @@
DEFAULT_MODE = RTLD_LOCAL
if _os.name == "posix" and _sys.platform == "darwin":
-import gestalt
-
-# gestalt.gestalt("sysv") returns the version number of the
-# currently active system file as BCD.
-# On OS X 10.4.6 -> 0x1046
-# On OS X 10.2.8 -> 0x1028
-# See also http://www.rgaros.nl/gestalt/
-#
# On OS X 10.3, we use RTLD_GLOBAL as default mode
# because RTLD_LOCAL does not work at least on some
-# libraries.
+# libraries. OS X 10.3 is Darwin 7, so we check for
+# that.
-if gestalt.gestalt("sysv") < 0x1040:
+if int(_os.uname()[2].split('.')[0]) < 8:
DEFAULT_MODE = RTLD_GLOBAL
from _ctypes import FUNCFLAG_CDECL as _FUNCFLAG_CDECL, \
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1203] ctypes doesn't work on Mac with --disable-toolbox-glue
Thomas Heller added the comment: IMO os.uname() is preferable. Committed as SVN rev 58415 in trunk. Thanks. -- assignee: -> theller resolution: -> accepted status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1203> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1295] logging records cache the result of formatException()
New submission from Thomas Heller: I needed two logging handlers in my application, one notifiying the user of errors, the other writing errors to a logfile. So I created a custom subclass of logging.Formatter and redefined the formatException() method that returned a summary of the exception like 'ZeroDivisionError' instead of the full traceback. Unfortunately the logging record caches the result of the handler.formatException() call in the exc_text variable, and the formatException() method of the second handler isn't called at all. The attached patch removes the caching and fixes the problem. -- components: Library (Lib) files: logging.patch keywords: patch messages: 56525 nosy: theller severity: normal status: open title: logging records cache the result of formatException() type: behavior versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file8563/logging.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1295> __Index: Lib/logging/__init__.py === --- Lib/logging/__init__.py (revision 58033) +++ Lib/logging/__init__.py (working copy) @@ -247,7 +247,6 @@ self.filename = pathname self.module = "Unknown module" self.exc_info = exc_info -self.exc_text = None # used to cache the traceback text self.lineno = lineno self.funcName = func self.created = ct @@ -420,14 +419,10 @@ record.asctime = self.formatTime(record, self.datefmt) s = self._fmt % record.__dict__ if record.exc_info: -# Cache the traceback text to avoid converting it multiple times -# (it's constant anyway) -if not record.exc_text: -record.exc_text = self.formatException(record.exc_info) -if record.exc_text: +exc_text = self.formatException(record.exc_info) if s[-1:] != "\n": s = s + "\n" -s = s + record.exc_text +s = s + exc_text return s # ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1295] logging records cache the result of formatException()
Thomas Heller added the comment: > > This is tough. On the one hand you are right that different classes that > > have different formatException() methods aren't treated correctly; on > > the other hand I think the caching is important for other cases where > > there are multiple loggers all using the default formatException(). > > > > I recommend that instead of getting rid of the cache, you fix your class > > by overriding format() to reset record.ex c_text and then calling the > > base class format() method. That is what I have been doing although I think that I have to reset record.exc_text also AFTER the call to format() for the following handlers, if any. So, should this issue be closed as 'wont fix' ? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1295> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1295] logging records cache the result of formatException()
Thomas Heller added the comment: I think that a warning or an example in the docs would be nice, but I have no time to make a patch for that. -- resolution: -> wont fix status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1295> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1319] py3k: fixes for test_ctypes
Thomas Heller added the comment: Guido van Rossum schrieb: > Looks good to me. I can check it in if Thomas is okay with that (or if > he remains silent long enough :-). Looks good to me too. Please check it in if you have time ;-) __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1319> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1319] py3k: fixes for test_ctypes
Thomas Heller added the comment:
Looking again, I found a bug in the patch.
In the function _get_args(), the local variable 'name' was
changed from 'char *' to 'PyObject *'. In line 2995, it is
passed to PyErr_Format with a '%s' format code:
if (name)
PyErr_Format(PyExc_TypeError,
==> "required argument '%s' missing", name);
A unittest but no fix for the bug for this issue is
attached (can I submit patches via mail?)
Added file: http://bugs.python.org/file8602/test_prototypes.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1319>
__Index: test_prototypes.py
===
--- test_prototypes.py (revision 58625)
+++ test_prototypes.py (working copy)
@@ -48,6 +48,24 @@
func.restype = c_long
func.argtypes = None
+def test_paramflags(self):
+# function returns c_void_p result,
+# and has a required parameter named 'input'
+prototype = CFUNCTYPE(c_void_p, c_void_p)
+func = prototype(("_testfunc_p_p", testdll),
+ ((1, "input"),))
+
+try:
+func()
+except TypeError as details:
+self.failUnlessEqual(str(details), "required argument 'input'
missing")
+else:
+self.fail("TypeError not raised")
+
+self.failUnlessEqual(func(None), None)
+self.failUnlessEqual(func(input=None), None)
+
+
def test_int_pointer_arg(self):
func = testdll._testfunc_p_p
func.restype = c_long
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1319] py3k: fixes for test_ctypes
Thomas Heller added the comment: Here's the bugfix - is it correct? Added file: http://bugs.python.org/file8603/_ctypes.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1319> __Index: Modules/_ctypes/_ctypes.c === --- Modules/_ctypes/_ctypes.c (revision 58639) +++ Modules/_ctypes/_ctypes.c (working copy) @@ -2992,7 +2992,7 @@ /* we can't currently emit a better error message */ if (name) PyErr_Format(PyExc_TypeError, -"required argument '%s' missing", name); +"required argument '%S' missing", name); else PyErr_Format(PyExc_TypeError, "not enough arguments"); ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1319] py3k: fixes for test_ctypes
Thomas Heller added the comment: Committed as rev 58642. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1319> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1324] r58034 breaks building _ctypes with the upstream libffi.
Thomas Heller added the comment: Maybe I should give up the idea to define the ffi_type_... types myself. Committed as rev 58655. Thanks. -- resolution: -> accepted status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1324> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1292] libffi needs an update to support mips64, arm and armeabi on linux
Thomas Heller added the comment: I'm unsure how to proceed with this. Replacing the copy of libffi in the ctypes sources - I'm very afraid to do that. It has it's own configure system, written by someone else. Then it has several changes from various people for Python, which would be overwritten. All these on systems that I do not have direct access to, and we do not have buildbots for all of them. So, it looks like --with-system-ffi should be made the default (on systems that have libffi installed?) There are also test failures since I committed the c_longdouble patch (on alpha debian, and S390 Debian, for example). Maybe newer libffi versions have a fix for that... Last comment: Experimental changes COULD be tested out in a branch, we would only have to manually trigger the build from the buildbot web pages. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1292> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1292] libffi needs an update to support mips64, arm and armeabi on linux
Thomas Heller added the comment: In the branches_ctypes-branch I hacked setup.py to always use an installed libffi if one is found. Then I triggered the trunk buildbots which failed or crashed before in some c_longdouble tests; the tests worked ok on them (ppc Debian unstable, and S-390 Debian). __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1292> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1292] libffi needs an update to support mips64, arm and armeabi on linux
Thomas Heller added the comment: I meant branches/ctypes_branch, of course. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1292> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1292] libffi needs an update to support mips64, arm and armeabi on linux
Thomas Heller added the comment: I have now made --with-system-ffi default to "yes" for Linux/alpha*, Linux/arm*, Linux/ppc*, and Linux/s390* machines. If you think it is needed for mips machines also please add this - there's no buildbot where I can check the result. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1292> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1388] py3k-pep3137: possible ref leak in ctypes
Thomas Heller added the comment: ./python Lib/test/regrtest.py -R:: test_ctypes does not report a leak, so I think there is no leak. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1388> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1388] py3k-pep3137: possible ref leak in ctypes
Thomas Heller added the comment: > $ ./python Lib/test/regrtest.py -R:: test_ctypes > test_ctypes > beginning 9 repetitions > 123456789 > . > test_ctypes leaked [-33, 0, 0, 0] references, sum=-33 > 1 test OK. > [101762 refs] Yes, I think this is ok. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1388> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1406] Use widechar api for os.environ
New submission from Thomas Heller:
This patch uses the windows widechar apis for os.environ. In this way,
environment variables that use umlauts can be accessed.
--
components: Interpreter Core, Windows
files: posixmodule.c.diff
keywords: patch, py3k
messages: 57265
nosy: theller
severity: normal
status: open
title: Use widechar api for os.environ
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file8715/posixmodule.c.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1406>
__Index: posixmodule.c
===
--- posixmodule.c (revision 58913)
+++ posixmodule.c (working copy)
@@ -340,7 +340,11 @@
convertenviron(void)
{
PyObject *d;
+#ifdef MS_WINDOWS
+ wchar_t **e;
+#else
char **e;
+#endif
d = PyDict_New();
if (d == NULL)
return NULL;
@@ -348,6 +352,38 @@
if (environ == NULL)
environ = *_NSGetEnviron();
#endif
+#ifdef MS_WINDOWS
+ /* _wenviron must be initialized in this way if the program is started
+ through main() instead of wmain(). */
+ _wgetenv(L"");
+ if (_wenviron == NULL)
+ return d;
+ /* This part ignores errors */
+ for (e = _wenviron; *e != NULL; e++) {
+ PyObject *k;
+ PyObject *v;
+ wchar_t *p = wcschr(*e, L'=');
+ if (p == NULL)
+ continue;
+ k = PyUnicode_FromWideChar(*e, (Py_ssize_t)(p-*e));
+ if (k == NULL) {
+ PyErr_Clear();
+ continue;
+ }
+ v = PyUnicode_FromWideChar(p+1, wcslen(p+1));
+ if (v == NULL) {
+ PyErr_Clear();
+ Py_DECREF(k);
+ continue;
+ }
+ if (PyDict_GetItem(d, k) == NULL) {
+ if (PyDict_SetItem(d, k, v) != 0)
+PyErr_Clear();
+ }
+ Py_DECREF(k);
+ Py_DECREF(v);
+ }
+#else
if (environ == NULL)
return d;
/* This part ignores errors */
@@ -375,6 +411,7 @@
Py_DECREF(k);
Py_DECREF(v);
}
+#endif
#if defined(PYOS_OS2)
{
APIRET rc;
@@ -4973,12 +5010,23 @@
static PyObject *
posix_putenv(PyObject *self, PyObject *args)
{
+#ifdef MS_WINDOWS
+wchar_t *s1, *s2;
+wchar_t *newenv;
+#else
char *s1, *s2;
char *newenv;
+#endif
PyObject *newstr;
size_t len;
- if (!PyArg_ParseTuple(args, "ss:putenv", &s1, &s2))
+ if (!PyArg_ParseTuple(args,
+#ifdef MS_WINDOWS
+ "uu:putenv",
+#else
+ "ss:putenv",
+#endif
+ &s1, &s2))
return NULL;
#if defined(PYOS_OS2)
@@ -4997,14 +5045,27 @@
return os2_error(rc);
} else {
#endif
-
/* XXX This can leak memory -- not easy to fix :-( */
- len = strlen(s1) + strlen(s2) + 2;
/* len includes space for a trailing \0; the size arg to
PyString_FromStringAndSize does not count that */
+#ifdef MS_WINDOWS
+ len = wcslen(s1) + wcslen(s2) + 2;
+ newstr = PyUnicode_FromUnicode(NULL, (int)len - 1);
+#else
+ len = strlen(s1) + strlen(s2) + 2;
newstr = PyString_FromStringAndSize(NULL, (int)len - 1);
+#endif
if (newstr == NULL)
return PyErr_NoMemory();
+#ifdef MS_WINDOWS
+ newenv = PyUnicode_AsUnicode(newstr);
+ _snwprintf(newenv, len, L"%s=%s", s1, s2);
+ if (_wputenv(newenv)) {
+Py_DECREF(newstr);
+posix_error();
+return NULL;
+ }
+#else
newenv = PyString_AS_STRING(newstr);
PyOS_snprintf(newenv, len, "%s=%s", s1, s2);
if (putenv(newenv)) {
@@ -5012,6 +5073,7 @@
posix_error();
return NULL;
}
+#endif
/* Install the first arg and newstr in posix_putenv_garbage;
* this will cause previous value to be collected. This has to
* happen after the real putenv() call because the old value
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1406] Use widechar api for os.environ
Thomas Heller added the comment: Committed as rev 58916. The getpath.c, sys.path, and sys.argv issues is much more difficult to fix IMO. If you write a testcase for THIS issue (os.environ), I'll start thinking on them. No promises, though. -- assignee: -> theller resolution: accepted -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1406> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1378] fromfd() and dup() for _socket on WIndows
Thomas Heller added the comment:
Christian Heimes schrieb:
> Neal, Thomas, what do you think about the patch? Your knowledge of the
> Windows API is greater than mine. Is the duplicate_socket() function ok?
> I don't want to apply a patch I don't fully understand.
>
> +#ifdef MS_WINDOWS
> +/* On Windows a socket is really a handle not an fd */
> +static SOCKET
> +duplicate_socket(SOCKET handle)
> +{
> + HANDLE newhandle;
> +
> + if (!DuplicateHandle(GetCurrentProcess(), (HANDLE)handle,
> +GetCurrentProcess(), &newhandle,
> +0, FALSE, DUPLICATE_SAME_ACCESS))
> + {
> + WSASetLastError(WSAEBADF);
> + return INVALID_SOCKET;
> + }
> + return (SOCKET)newhandle;
> +}
> +#define dup(fd) duplicate_socket(fd)
> +#define SOCKETCLOSE closesocket
> +#define NO_MAKEFILE /* socket handles can't be treated like file handles */
> +#endif
Not much time, so only one comment:
Is it wise to call WSASetLastError(WSAEBADF) instead of calling GetLastError()?
Thomas
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1378>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1505] Changes to PyMethod_New breaks ctypes on Windows
Thomas Heller added the comment:
Christian Heimes schrieb:
> > New submission from Christian Heimes:
> >
> > The problem is in _ctypes.c:create_comerror() around line 4620.
The code tries to populate a dict with methods and finally pass them to
PyErr_NewException("_ctypes.COMError", NULL, dict);
I have no idea what to do. What do I have to put into the dict?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1505>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1506] func alloca inside ctypes lib needs #include on solaris
Thomas Heller added the comment: > Greg Couch added the comment: > > Turns out callproc.c forgot to include after > which conditionally includes alloca.h. So it's a one-line fix. > This would not work. is a file private to libffi; when Python is configured to use the system ffi-library (--with-systemffi) this file is not available. I would tend to replace the three alloca() calls in the function _CallProc() in callbacks.c with calls to malloc(). All the other occurrences of alloca() are only compiled on windows. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1506> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: [issue10296] ctypes catches BreakPoint error on windows 32
ctypes has _always_ catched exceptions raised in function calls. On Windows ;-). ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1793] ctypes.util.find_msvcrt() function
Thomas Heller <[EMAIL PROTECTED]> added the comment: Committed in trunk as rev. 63395. I've changed the code that Amaury suggested so that None is returned when get_build_version() returns None. Thanks. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1793> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2783] ctypes.util.find_library() doesn't find OS X .bundle or .so libraries
Thomas Heller <[EMAIL PROTECTED]> added the comment: The OS X find_library code was not written by me, the code was ripped from Bob Ippolitos macholib. Can some OS X expert please look into this? Shamelessly assigning to Ronald - feel free to unassign if you have no time. -- assignee: theller -> ronaldoussoren nosy: +ronaldoussoren __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2783> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2783] ctypes.util.find_library() doesn't find OS X .bundle or .so libraries
Thomas Heller <[EMAIL PROTECTED]> added the comment: Thanks, Ronald. Sounds like this bug could be closed then. Bill, if you want a library search function with different semantics, I suggest you open a feature request, describe the sematics that should be used and (ideally) provide a patch. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2783> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2939] Apache mod_python python-func strftime
Thomas Heller <[EMAIL PROTECTED]> added the comment: Has nothing to do with ctypes. -- assignee: theller -> __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2939> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1798] Add ctypes calling convention that allows safe access of errno
Thomas Heller <[EMAIL PROTECTED]> added the comment: That's a great idea. > Just before doing a C library function call, > ctypes would copy this variable into the real C-level errno; and Is the ctypes.set_errno(...) function really needed? Wouldn't it be sufficient if errno is simply set to zero before each function call? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1798> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1798] Add ctypes calling convention that allows safe access of errno
Thomas Heller <[EMAIL PROTECTED]> added the comment: But would it hurt to set errno to zero before *any* function call? My experiments show that it is faster to clear errno always instead of trying to get a previously set value from tls storage in a ctypes-global object created by calling "threading.local()". __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1798> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1798] Add ctypes calling convention that allows safe access of errno
Thomas Heller <[EMAIL PROTECTED]> added the comment: This does not work because Python can run arbitrary code, even in the same thread, between the call to a function in a shared library and the call to get_errno(). __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1798> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1798] Add ctypes calling convention that allows safe access of errno
Thomas Heller <[EMAIL PROTECTED]> added the comment: > How can Python run arbitrary code between the return from a ctypes > method and the next Python instruction? None of the code should have any > effect on errno. By freeing objects because their refcount has reached zero? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1798> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1798] Add ctypes calling convention that allows safe access of errno
Thomas Heller <[EMAIL PROTECTED]> added the comment:
>> Using the native errno instead of a custom TLS value is bad because a
>> lot of things can occur
>
> So what's the semantics of set_errno then? Set the real errno? If so,
> what if it gets changed between the call to set_errno, and the actual
> invocation of API function? Set the TLS errno? If so, when does it get
> copied into the real errno?
AFAIU, set_errno/get_errno should provide a ctypes-private copy of the real
errno.
The copy is copied into the 'real' errno just before ffi_call (in
Modules/_ctypes/callproc.c),
and the real errno is copied in to ctypes copy right after the call.
Probably the real errno from before this action should be restored at the end.
Code that I have in mind:
__thread int _ctypes_errno; /* ctypes-private global error number in thread
local storage */
static int _call_function_pointer(...)
{
int old_errno;
.
.
old_errno = errno;
errno = _ctypes_errno;
ffi_call();
_ctypes_errno = errno;
errno = old_errno;
.
.
}
static PyObject *
_ctypes_set_errno(PyObject *self, Pyobject *args)
{
.
_ctypes_errno = parsed_argument;
.
}
static PyObject *
_ctypes_get_errno(PyObject *self, Pyobject *args)
{
return PyInt_FromLong(_ctypes_errno);
}
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1798>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1798] Add ctypes calling convention that allows safe access of errno
Thomas Heller <[EMAIL PROTECTED]> added the comment: >> AFAIU, set_errno/get_errno should provide a ctypes-private copy of the real >> errno. >> The copy is copied into the 'real' errno just before ffi_call (in >> Modules/_ctypes/callproc.c), >> and the real errno is copied in to ctypes copy right after the call. > > If you clear errno, anyway, you can also drop the set_errno call, and My code sample did not intend to clear errno, it was intended to set errno to the last value that the ctypes-copy had before the call. > zero-initialize errno before each call. The point of set_errno would > be that you have the choice of *not* calling it, i.e. passing into > the function the errno value that was there before you made the API > call. If you fill something else into errno always, the application has > no way of not modifying errno before the API call. To make my point clear (in case is isn't already): In the code sample that Armin posted, it is impossible to guarantee that no stdlib function is called between the readdir() and the get_errno() call: dirent = linux_c_lib.readdir(byref(dir)) if not dirent: if ctypes.get_errno() == 0: Consider the garbage collector free some objects that release resources they have, in other words call functions different from free(3). Similarly for calling set_errno() or not calling it; other stdlib function calls in the meantime may have changed errno and that might not be what the Python programmer expects. Anyway, how can we proceed? Do you have a suggestion? Should set_errno() set a flag that is examined and consumed before call_function_pointer() is called? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1798> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2936] ctypes.util.find_library() doesn't consult LD_LIBRARY_PATH
Thomas Heller <[EMAIL PROTECTED]> added the comment:
To be honest, I do not understand this request and the discussion.
ctypes.util.find_library(), as dcumented, is supposed to simulate what
the linker does: find the name of a shared library. For example,
it returns 'libc.so.6' when called as ctypes.util.find_library('c').
AFAIK (and I don't know very much about posix shared libs or linkers)
the linker does not pay attention to (DY)LD_LIBRARY_PATH env var.
dlopen(shared-lib-name) does use this env vars, but this behaviour is
already built into dlopen.
--
assignee: -> theller
nosy: +theller
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2936>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1798] Add ctypes calling convention that allows safe access of errno
Thomas Heller <[EMAIL PROTECTED]> added the comment: Ok, here is the plan (basically Armin's proposal): ctypes maintains a gloabl, but thread-local, variable that contains an error number; called 'ctypes_errno' for this discussion. ctypes.set_errno(value) copies 'value' into ctypes_errno, and returns the old value. ctypes.get_errno() returns the current ctypes_errno value. Foreign functions created with CDLL(..., use_errno=True), when called, copy the ctypes_errno value into the real errno just before they are called, and copy the real errno value into ctypes_errno. The 'use_errno' parameter defaults to False, in this case ctypes_errno is not touched. The same scheme is implemented on Windows for GetLastError() and SetLastError(), the variable is named 'ctypes_LastError', and the CDLL and WinDLL optional parameter is named 'use_LastError', and also defaults to False. Armin Rigo schrieb: > (Another note: the C-level errno and the TLS copy should also be > synchronized when the C code invokes a Python callback.) Not sure what this is for, please proofread the patch when I attach one. Even better, someone could supply test-cases for all this, either as executable code or as prosa. > (A related issue that we may or may not care about: it's more than > likely that various people have already come up with various workarounds > to handle errno, and these workarounds will probably stop working after > ctypes is changed...) Since the new behaviour will only be invoked when use_errno or use_LastError is used, they should be able to still use their workarounds. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1798> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1779233] PyThreadState_SetAsyncExc and the main thread
Changes by Thomas Heller <[EMAIL PROTECTED]>: -- assignee: theller -> ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1779233> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1797] ctypes function pointer enhancements
Changes by Thomas Heller <[EMAIL PROTECTED]>: ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1797> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1797] ctypes function pointer enhancements
Thomas Heller <[EMAIL PROTECTED]> added the comment: NULL function pointers are have a boolean False value now; svn rev 63792 (trunk) and rev 63793 (py3k). ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1797> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1798] Add ctypes calling convention that allows safe access of errno
Thomas Heller <[EMAIL PROTECTED]> added the comment:
Here is a patch implementing the plan. This text could serve as a start for the
documentation, but it also describes the current implementation. Usage recipes
should probably be added:
/*
ctypes maintains a module-global, but thread-local, variable that contains
an error number; called 'ctypes_errno' for this discussion. This variable
is a private copy of the stdlib 'errno' value; it is swapped with the
'errno' variable on several occasions.
Foreign functions created with CDLL(..., use_errno=True), when called, swap
the values just before they are actual function call, and swapped again
afterwards. The 'use_errno' parameter defaults to False, in this case
ctypes_errno is not touched.
The values are also swapped immeditately before and after ctypes callback
functions are called, if the callbacks are constructed using the new
optional use_errno parameter for CFUNCTYPE(..., use_errno=TRUE) or
WINFUNCTYPE(..., use_errno=True).
Two new ctypes functions are provided to access the 'ctypes_errno' value
from Python:
- ctypes.set_errno(value) sets ctypes_errno to 'value', the previous
ctypes_errno value is returned.
- ctypes.get_errno() returns the current ctypes_errno value.
The same scheme is implemented on Windows for GetLastError() and
SetLastError(), and the CDLL and WinDLL optional parameter is named
'use_LastError', and also defaults to False.
On Windows, TlsSetValue and TlsGetValue calls are used to provide thread
local storage for the variables; ctypes compiled with __GNUC__ uses __thread
variables.
*/
Added file: http://bugs.python.org/file10480/ctypes-errno-3.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1798>
___Index: Lib/ctypes/__init__.py
===
--- Lib/ctypes/__init__.py (revision 63822)
+++ Lib/ctypes/__init__.py (working copy)
@@ -33,7 +33,9 @@
DEFAULT_MODE = RTLD_GLOBAL
from _ctypes import FUNCFLAG_CDECL as _FUNCFLAG_CDECL, \
- FUNCFLAG_PYTHONAPI as _FUNCFLAG_PYTHONAPI
+ FUNCFLAG_PYTHONAPI as _FUNCFLAG_PYTHONAPI, \
+ FUNCFLAG_USE_ERRNO as _FUNCFLAG_USE_ERRNO, \
+ FUNCFLAG_USE_LASTERROR as _FUNCFLAG_USE_LASTERROR
"""
WINOLEAPI -> HRESULT
@@ -73,8 +75,8 @@
return create_string_buffer(init, size)
_c_functype_cache = {}
-def CFUNCTYPE(restype, *argtypes):
-"""CFUNCTYPE(restype, *argtypes) -> function prototype.
+def CFUNCTYPE(restype, *argtypes, **kw):
+"""CFUNCTYPE(restype, *argtypes, **kw) -> function prototype.
restype: the result type
argtypes: a sequence specifying the argument types
@@ -88,14 +90,21 @@
prototype((ordinal number, dll object)[, paramflags]) -> foreign function
exported by ordinal
prototype((function name, dll object)[, paramflags]) -> foreign function
exported by name
"""
+flags = _FUNCFLAG_CDECL
+if kw.pop("use_errno", False):
+flags |= _FUNCFLAG_USE_ERRNO
+if kw.pop("use_LastError", False):
+flags |= _FUNCFLAG_USE_LASTERROR
+if kw:
+raise ValueError("unexpected keyword argument(s) %s" % kw.keys())
try:
-return _c_functype_cache[(restype, argtypes)]
+return _c_functype_cache[(restype, argtypes, flags)]
except KeyError:
class CFunctionType(_CFuncPtr):
_argtypes_ = argtypes
_restype_ = restype
-_flags_ = _FUNCFLAG_CDECL
-_c_functype_cache[(restype, argtypes)] = CFunctionType
+_flags_ = flags
+_c_functype_cache[(restype, argtypes, flags)] = CFunctionType
return CFunctionType
if _os.name in ("nt", "ce"):
@@ -106,16 +115,23 @@
_FUNCFLAG_STDCALL = _FUNCFLAG_CDECL
_win_functype_cache = {}
-def WINFUNCTYPE(restype, *argtypes):
+def WINFUNCTYPE(restype, *argtypes, **kw):
# docstring set later (very similar to CFUNCTYPE.__doc__)
+flags = _FUNCFLAG_STDCALL
+if kw.pop("use_errno", False):
+flags |= _FUNCFLAG_USE_ERRNO
+if kw.pop("use_LastError", False):
+flags |= _FUNCFLAG_USE_LASTERROR
+if kw:
+raise ValueError("unexpected keyword argument(s) %s" % kw.keys())
try:
-return _win_functype_cache[(restype, argtypes)]
+return _win_functype_cache[(restype, argtypes, flags)]
except KeyError:
class WinFunctionType(_CFuncPtr):
_argtypes_ = argtypes
_restype_ = restype
-_flags_ = _FUNCFLAG_STDCALL
-_win_functype_cache[(restype, argtypes)]
[issue1798] Add ctypes calling convention that allows safe access of errno
Thomas Heller <[EMAIL PROTECTED]> added the comment: Thomas Heller schrieb: > Here is a patch implementing the plan. ctypes-errno-3.patch, in case of doubt. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1798> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2936] ctypes.util.find_library() doesn't consult LD_LIBRARY_PATH
Thomas Heller <[EMAIL PROTECTED]> added the comment: > The question is, which linker? I think it should be ld.so, which links "on > demand", and does pay attention to LD_LIBRARY_PATH. I'm not sure what the > point of find_library() is, otherwise. The best explanation is in the python docs: http://docs.python.org/lib/ctypes-finding-shared-libraries.html ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2936> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2936] ctypes.util.find_library() doesn't consult LD_LIBRARY_PATH
Changes by Thomas Heller <[EMAIL PROTECTED]>: -- resolution: -> invalid status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2936> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3030] compiler warning on HP-UX
New submission from Thomas Heller <[EMAIL PROTECTED]>: On HP-UX, there is a compiler warning about _POSIX_C_SOURCE redefined: bash-2.04$ make gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c In file included from Include/Python.h:8, from ./Modules/python.c:3: ./pyconfig.h:1023:1: warning: "_POSIX_C_SOURCE" redefined :3:1: warning: this is the location of the previous definition gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -o Parser/acceler.o Parser/acceler.c In file included from Include/Python.h:8, from Include/pgenheaders.h:10, from Parser/acceler.c:13: ./pyconfig.h:1023:1: warning: "_POSIX_C_SOURCE" redefined ... -- components: Build messages: 67649 nosy: theller severity: normal status: open title: compiler warning on HP-UX versions: Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3030> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1798] Add ctypes calling convention that allows safe access of errno
Thomas Heller <[EMAIL PROTECTED]> added the comment: A different patch but implementing the same functionality was now committed as trunk rev 63977. -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1798> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1798] Add ctypes calling convention that allows safe access of errno
Thomas Heller <[EMAIL PROTECTED]> added the comment: >> (Another note: the C-level errno and the TLS copy should also be >> synchronized when the C code invokes a Python callback.) > > What I meant is what should occur when a pure Python function is used > as a callback. At this point there is already some logic e.g. to > re-acquire the GIL if necessary. Maybe it needs to grow logic to > optionally copy the C-level errno into the TLS variable at the start, > and at the end copy it back into the C-level errno at the end, for the > cases where the C code expects the callback to be able to set errno. I figured that out in the meantime and implemented it in this way. See the code around line 295 in Modules/_ctypes/callbacks.c. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1798> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3124] test_multiprocessing segfaults on Windows
New submission from Thomas Heller <[EMAIL PROTECTED]>: When Python shuts down after running test_multiprocessing on Windows, a segfault occurs (this is with a debug build from trunk): > python26_d.dll!_Py_ForgetReference(_object * op=0x012de740) Line 2023 + 0xf bytes C python26_d.dll!_Py_Dealloc(_object * op=0x012de740) Line 2043 + 0x9 bytes C python26_d.dll!tupledealloc(PyTupleObject * op=0x00d58c78) Line 169 + 0x8a bytes C python26_d.dll!_Py_Dealloc(_object * op=0x00d58c78) Line 2044 + 0x7 bytes C python26_d.dll!PyObject_CallFunctionObjArgs(_object * callable=0x00d64090, ...) Line 2716 + 0x51 bytes C python26_d.dll!handle_callback(_PyWeakReference * ref=0x012de740, _object * callback=0x00d64090) Line 864 + 0xf bytesC python26_d.dll!PyObject_ClearWeakRefs(_object * object=0x012bcc98) Line 910 + 0xd bytesC python26_d.dll!func_dealloc(PyFunctionObject * op=0x012bcc98) Line 453 + 0x9 bytes C python26_d.dll!_Py_Dealloc(_object * op=0x012bcc98) Line 2044 + 0x7 bytes C python26_d.dll!tupledealloc(PyTupleObject * op=0x012ddeb8) Line 169 + 0x8a bytes C python26_d.dll!_Py_Dealloc(_object * op=0x012ddeb8) Line 2044 + 0x7 bytes C python26_d.dll!clear_slots(_typeobject * type=0x00cbbac8, _object * self=0x012de740) Line 821 + 0x51 bytes C python26_d.dll!subtype_dealloc(_object * self=0x012de740) Line 950 + 0xd bytes C python26_d.dll!_Py_Dealloc(_object * op=0x012de740) Line 2044 + 0x7 bytes C python26_d.dll!dict_dealloc(_dictobject * mp=0x00d538c0) Line 907 + 0x6c bytes C python26_d.dll!_Py_Dealloc(_object * op=0x00d538c0) Line 2044 + 0x7 bytes C python26_d.dll!dict_dealloc(_dictobject * mp=0x00d536c8) Line 907 + 0x6c bytes C python26_d.dll!_Py_Dealloc(_object * op=0x00d536c8) Line 2044 + 0x7 bytes C python26_d.dll!instance_dealloc(PyInstanceObject * inst=0x00d60bf8) Line 668 + 0x6c bytes C python26_d.dll!_Py_Dealloc(_object * op=0x00d60bf8) Line 2044 + 0x7 bytes C python26_d.dll!insertdict(_dictobject * mp=0x00d53620, _object * key=0x00d5c9b8, long hash=-1896994012, _object * value=0x1e2bb004) Line 455 + 0x51 bytesC python26_d.dll!PyDict_SetItem(_object * op=0x00d53620, _object * key=0x00d5c9b8, _object * value=0x1e2bb004) Line 697 + 0x15 bytes C python26_d.dll!_PyModule_Clear(_object * m=0x00d63968) Line 125 + 0x12 bytes C python26_d.dll!PyImport_Cleanup() Line 479 + 0x9 bytes C python26_d.dll!Py_Finalize() Line 452 C python26_d.dll!Py_Exit(int sts=0) Line 1690C python26_d.dll!handle_system_exit() Line + 0x9 bytes C python26_d.dll!PyErr_PrintEx(int set_sys_last_vars=1) Line 1123 C python26_d.dll!PyErr_Print() Line 1030 + 0x7 bytes C python26_d.dll!PyRun_SimpleFileExFlags(_iobuf * fp=0x10311448, const char * filename=0x009d5d93, int closeit=1, PyCompilerFlags * flags=0x0022ff30) Line 931 C python26_d.dll!PyRun_AnyFileExFlags(_iobuf * fp=0x10311448, const char * filename=0x009d5d93, int closeit=1, PyCompilerFlags * flags=0x0022ff30) Line 731 + 0x15 bytesC python26_d.dll!Py_Main(int argc=5, char * * argv=0x009d5d68) Line 600 + 0x39 bytesC python_d.exe!main(int argc=5, char * * argv=0x009d5d68) Line 23 + 0xe bytes C python_d.exe!__tmainCRTStartup() Line 582 + 0x19 bytes C python_d.exe!mainCRTStartup() Line 399 C -- messages: 68274 nosy: theller severity: normal status: open title: test_multiprocessing segfaults on Windows type: crash versions: Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3124> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3125] test_multiprocessing causes test_ctypes to fail
New submission from Thomas Heller <[EMAIL PROTECTED]>: test_ctypes, when run after testmultiprocessing, fails: ... == ERROR: test_simple (ctypes.test.test_pickling.PickleTest) -- Traceback (most recent call last): File "c:\svn\trunk\lib\ctypes\test\test_pickling.py", line 29, in test_simple dst = self.loads(self.dumps(src)) File "c:\svn\trunk\lib\ctypes\test\test_pickling.py", line 19, in dumps return pickle.dumps(item) File "c:\svn\trunk\lib\pickle.py", line 1366, in dumps Pickler(file, protocol).dump(obj) File "c:\svn\trunk\lib\pickle.py", line 224, in dump self.save(obj) File "c:\svn\trunk\lib\pickle.py", line 301, in save rv = reduce(obj) File "c:\svn\trunk\lib\multiprocessing\sharedctypes.py", line 121, in reduce_ctype assert_spawning(obj) File "c:\svn\trunk\lib\multiprocessing\forking.py", line 25, in assert_spawning ' through inheritance' % type(self).__name__ RuntimeError: c_long objects should only be shared between processes through inheritance == ERROR: test_simple (ctypes.test.test_pickling.PickleTest_1) -- Traceback (most recent call last): File "c:\svn\trunk\lib\ctypes\test\test_pickling.py", line 29, in test_simple dst = self.loads(self.dumps(src)) File "c:\svn\trunk\lib\ctypes\test\test_pickling.py", line 71, in dumps return pickle.dumps(item, 1) File "c:\svn\trunk\lib\pickle.py", line 1366, in dumps Pickler(file, protocol).dump(obj) File "c:\svn\trunk\lib\pickle.py", line 224, in dump self.save(obj) File "c:\svn\trunk\lib\pickle.py", line 301, in save rv = reduce(obj) File "c:\svn\trunk\lib\multiprocessing\sharedctypes.py", line 121, in reduce_ctype assert_spawning(obj) File "c:\svn\trunk\lib\multiprocessing\forking.py", line 25, in assert_spawning ' through inheritance' % type(self).__name__ RuntimeError: c_long objects should only be shared between processes through inheritance == ERROR: test_simple (ctypes.test.test_pickling.PickleTest_2) -- Traceback (most recent call last): File "c:\svn\trunk\lib\ctypes\test\test_pickling.py", line 29, in test_simple dst = self.loads(self.dumps(src)) File "c:\svn\trunk\lib\ctypes\test\test_pickling.py", line 75, in dumps return pickle.dumps(item, 2) File "c:\svn\trunk\lib\pickle.py", line 1366, in dumps Pickler(file, protocol).dump(obj) File "c:\svn\trunk\lib\pickle.py", line 224, in dump self.save(obj) File "c:\svn\trunk\lib\pickle.py", line 301, in save rv = reduce(obj) File "c:\svn\trunk\lib\multiprocessing\sharedctypes.py", line 121, in reduce_ctype assert_spawning(obj) File "c:\svn\trunk\lib\multiprocessing\forking.py", line 25, in assert_spawning ' through inheritance' % type(self).__name__ RuntimeError: c_long objects should only be shared between processes through inheritance -- -- messages: 68276 nosy: theller severity: normal status: open title: test_multiprocessing causes test_ctypes to fail versions: Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3125> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3124] test_multiprocessing segfaults on Windows
Thomas Heller <[EMAIL PROTECTED]> added the comment: Yes, the patch weakref_cycle.patch from #3100 fixes the problem. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3124> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3125] test_multiprocessing causes test_ctypes to fail
Thomas Heller <[EMAIL PROTECTED]> added the comment: IMO this problem occurs because multiprocessing registers pickling support for ctypes, but the ctypes in trunk already has support for pickling. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3125> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3125] test_multiprocessing causes test_ctypes to fail
Thomas Heller <[EMAIL PROTECTED]> added the comment: Adam Olsen schrieb: > Thomas, do you have a specific command to reproduce this? It runs fine > if I do "./python -m test.regrtest -v test_multiprocessing test_ctypes". > That's with amaury's patch from 3100 applied. It seems the failure only occurs on Windows. On linux it does work for me too. See the traceback that I posted, and this: http://www.python.org/dev/buildbot/trunk/x86%20XP-3%20trunk/builds/1606/step-test/0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3125> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3125] test_multiprocessing causes test_ctypes to fail
Thomas Heller <[EMAIL PROTECTED]> added the comment: > Adam Olsen <[EMAIL PROTECTED]> added the comment: > > I see no common symbols between #3102 and #3092, so unless I missed > something, they shouldn't be involved. > > I second the notion that multiprocessing's use of pickle is the > triggering factor. Registering so many types is ugly, and IMO it > shouldn't register anything it doesn't control. We should either > register them global or not at all, and *never* as a side-effect of > loading a separate module. > > I do see some win32-specific behaviour, which may be broken. Thomas, > wanna try commenting out these two lines in sharedtypes.py:rebuild_ctype? > > if sys.platform == 'win32' and type_ not in copy_reg.dispatch_table: > copy_reg.pickle(type_, reduce_ctype) This fixes the failure in test_ctypes, but test_multiprocessing no longer works: c:\svn\trunk\PCbuild>.\\python_d -E -tt ../lib/test/regrtest.py test_multiprocessing test_ctypes test_multiprocessing Traceback (most recent call last): File "", line 1, in File "c:\svn\trunk\lib\multiprocessing\forking.py", line 297, in main self = load(from_parent) EOFError [48274 refs] Traceback (most recent call last): File "", line 1, in File "c:\svn\trunk\lib\multiprocessing\forking.py", line 297, in main self = load(from_parent) EOFError [48763 refs] test test_multiprocessing failed -- errors occurred; run in verbose mode for details test_ctypes 1 test OK. 1 test failed: test_multiprocessing [118894 refs] c:\svn\trunk\PCbuild> ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3125> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3124] test_multiprocessing segfaults on Windows
Thomas Heller <[EMAIL PROTECTED]> added the comment: > Thomas Heller <[EMAIL PROTECTED]> added the comment: > > Yes, the patch weakref_cycle.patch from #3100 fixes the problem. BTW: I also get a segfault on Linux, which is fixed by this patch. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3124> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3125] test_multiprocessing causes test_ctypes to fail
Thomas Heller <[EMAIL PROTECTED]> added the comment: roudkerk schrieb: > roudkerk <[EMAIL PROTECTED]> added the comment: > > This patch to sharedctypes should fix the problem by adding a > __reduce_ex__() method to a shared ctype object instead of using copy_reg. I can confirm that the patch fixes the problem on Windows (running test_ctypes before test_multiprocessing). However, the patch did not apply cleanly to current SVN trunk - I had to manually patch the code. I'll attach the patch that I have now when I run 'svn diff' as multiprocessing.patch (hope it works, sending as email attachment). Added file: http://bugs.python.org/file10654/multiprocessing.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3125> ___Index: Lib/multiprocessing/sharedctypes.py === --- Lib/multiprocessing/sharedctypes.py (revision 64378) +++ Lib/multiprocessing/sharedctypes.py (working copy) @@ -9,7 +9,6 @@ import sys import ctypes import weakref -import copy_reg from multiprocessing import heap, RLock from multiprocessing.forking import assert_spawning @@ -33,17 +32,13 @@ # # -def _new_value(type_): -size = ctypes.sizeof(type_) -wrapper = heap.BufferWrapper(size) -return rebuild_ctype(type_, wrapper, None) - def RawValue(typecode_or_type, *args): ''' Returns a ctypes object allocated from shared memory ''' type_ = typecode_to_type.get(typecode_or_type, typecode_or_type) -obj = _new_value(type_) +type_size = ctypes.sizeof(type_) +obj = build_ctype(type_, heap.BufferWrapper(type_size), None) ctypes.memset(ctypes.addressof(obj), 0, ctypes.sizeof(obj)) obj.__init__(*args) return obj @@ -53,14 +48,16 @@ Returns a ctypes array allocated from shared memory ''' type_ = typecode_to_type.get(typecode_or_type, typecode_or_type) +type_size = ctypes.sizeof(type_) if isinstance(size_or_initializer, int): -type_ = type_ * size_or_initializer -return _new_value(type_) +size = size_or_initializer +obj = build_ctype(type_, heap.BufferWrapper(type_size*size), size) +ctypes.memset(ctypes.addressof(obj), 0, ctypes.sizeof(obj)) else: -type_ = type_ * len(size_or_initializer) -result = _new_value(type_) -result.__init__(*size_or_initializer) -return result +size = len(size_or_initializer) +obj = build_ctype(type_, heap.BufferWrapper(type_size*size), size) +obj.__init__(*size_or_initializer) +return obj def Value(typecode_or_type, *args, **kwds): ''' @@ -117,20 +114,18 @@ # Functions for pickling/unpickling # -def reduce_ctype(obj): -assert_spawning(obj) -if isinstance(obj, ctypes.Array): -return rebuild_ctype, (obj._type_, obj._wrapper, obj._length_) -else: -return rebuild_ctype, (type(obj), obj._wrapper, None) - -def rebuild_ctype(type_, wrapper, length): +def build_ctype(type_, wrapper, length): if length is not None: -type_ = type_ * length -if sys.platform == 'win32' and type_ not in copy_reg.dispatch_table: -copy_reg.pickle(type_, reduce_ctype) -obj = type_.from_address(wrapper.get_address()) +obj = (type_ * length).from_address(wrapper.get_address()) +else: +obj = type_.from_address(wrapper.get_address()) obj._wrapper = wrapper +if sys.platform == 'win32': +def __reduce_ex__(proto): +return build_ctype, (type_, wrapper, length) +# It appears that assigning to obj.__reduce_ex__ will override +# type(obj).__reduce__, but that assigning to obj.__reduce__ will not. +obj.__reduce_ex__ = __reduce_ex__ return obj # ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3258] ctypes assertion failure in trunk
Thomas Heller <[EMAIL PROTECTED]> added the comment: Thanks for the heads up. Fixed in trunk (rev 64971) and py3k (rev 64972). I used "&B" (pointer to bytes) as the format string for pointer to incomplete structure, not "&P". -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3258> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3313] dlopen() error with no error message from dlerror()
Thomas Heller <[EMAIL PROTECTED]> added the comment: I can confirm the problem on ubuntu linux. -- assignee: -> theller nosy: +theller ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3313> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3313] dlopen() error with no error message from dlerror()
Thomas Heller <[EMAIL PROTECTED]> added the comment: Thanks for the patch, fixed in trunk rev 64977 and py3k rev 64978. -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3313> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2470] Need fixer for dl (removed) -> ctypes module
Thomas Heller <[EMAIL PROTECTED]> added the comment: I can review and try out the fixer if someone provides a patch. OTOH I have never used the dl module. Note that dl exposed a lot of RTLD_ constants that ctypes does not yet, so there should be a patch for ctypes also. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2470> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3383] ctypes.util fails to find libc in some environments
Thomas Heller <[EMAIL PROTECTED]> added the comment: Well, I have no idea what the standard setup on posix boxes is - should objdump and ldconfig be on $PATH or not? Regarding the groups in the regexp: It is my understanding that the parens do not matter because .group(0) is returned, which contains the entire matching string anyway - do I overlook something? Please note that the find_library() code was not written by myself ;-( ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3383> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3554] ctypes.wstring_at and string_at call Python API without the GIL
Thomas Heller <[EMAIL PROTECTED]> added the comment: Good catch! Indeed, when PyString_FromString or PyUnicode_FromWideChar fail, Python crashes with Fatal Python error: PyThreadState_Get: no current thread in a debug build, and an access violation in a release build (tested on Windows). Also, your patch suggestion is absolutely correct and fixes the problem. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3554> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3554] ctypes.wstring_at and string_at call Python API without the GIL
Thomas Heller <[EMAIL PROTECTED]> added the comment: This is fixed now in SVN, in trunk, branches/py3k, and branches/release25-maint. Thanks again. -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3554> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3265] Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error: `MAP_ANONYMOUS' undeclared
Thomas Heller <[EMAIL PROTECTED]> added the comment: Here is a patch for Modules/_ctypes/malloc_closure.c that may work (totally untested). The code snippet is copied from Modules/mmapmodule.c. -- keywords: +patch Added file: http://bugs.python.org/file11161/malloc_closure.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3265> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3265] Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error: `MAP_ANONYMOUS' undeclared
Thomas Heller <[EMAIL PROTECTED]> added the comment: Corrected the patch. Added file: http://bugs.python.org/file11162/malloc_closure.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3265> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3265] Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error: `MAP_ANONYMOUS' undeclared
Changes by Thomas Heller <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11161/malloc_closure.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3265> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3612] Add some basic mssing types in ctypes.wintypes
Thomas Heller <[EMAIL PROTECTED]> added the comment: I have no objections against this patch - feel free to check it in if it is not too late before the beta. Also I think that LPDWORD and friends are a good idea, you should extend the patch with them. -- assignee: theller -> ocean-city resolution: -> accepted ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3612> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3617] Add MS EULA to the list of third-party licenses in the Windows installer
Changes by Thomas Heller <[EMAIL PROTECTED]>: -- nosy: +theller ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3617> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3612] Add some basic mssing types in ctypes.wintypes
Thomas Heller <[EMAIL PROTECTED]> added the comment: I think this is too fancy. I would prefer to spell the definitions out like this: LPDWORD = PDWORD = POINTER(DWORD) LPCSTR = LPSTR = c_wchar_p We could avoid the giant __all__ list when we 'import ctypes as _ctypes' and write (for example): DWORD = _ctypes.c_ulong ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3612> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2764] c_char doesn't implement py3k buffer interface
Thomas Heller <[EMAIL PROTECTED]> added the comment: The test has already been fixed and reenabled in rev 65849. -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2764> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2404] Backport ctypes support for buffer protocol to Python 2.6 (ref issue1971)
Thomas Heller <[EMAIL PROTECTED]> added the comment: I forgot to close this issue. Already implemented in svn rev 63962. -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2404> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3785] Can't build ctypes of Python 2.5.2 with Sun Studio 12
Thomas Heller <[EMAIL PROTECTED]> added the comment: The libffi library in Python 2.5 is too old and won't be upgraded to a newer version. I see several possibilities for you: - Use Python 2.6 (if you can live with the beta or wait for the release) - Use Python 2.5, compile with GCC - Use Python 2.5, and build/install the ctypes version from Python SVN trunk as add-on module, it is available here: http://svn.python.org/projects/ctypes/branches/ctypes-1.1/ Closing as wont fix, sorry. -- resolution: -> wont fix status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3785> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2145] ctypes.util.find_library(): posix .so without SONAME
Thomas Heller <[EMAIL PROTECTED]> added the comment: Cool. -- resolution: -> invalid status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2145> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3870] Parser/asdl_c.py requires python in order to build python
Thomas Heller <[EMAIL PROTECTED]> added the comment: I think it would be a good idea to change the Makefile so that it touches these files when no python interpreter is available. -- nosy: +theller ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3870> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3547] Ctypes is confused by bitfields of varying integer types
Thomas Heller <[EMAIL PROTECTED]> added the comment: Here is a patch, with test, that fixes this problem. -- keywords: +needs review, patch Added file: http://bugs.python.org/file11513/bitfields.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3547> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3547] Ctypes is confused by bitfields of varying integer types
Thomas Heller <[EMAIL PROTECTED]> added the comment: Updated patch. Added file: http://bugs.python.org/file11514/bitfields-2.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3547> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3547] Ctypes is confused by bitfields of varying integer types
Changes by Thomas Heller <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11513/bitfields.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3547> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3547] Ctypes is confused by bitfields of varying integer types
Thomas Heller <[EMAIL PROTECTED]> added the comment: Updated the unittest so that it works on Windows, too. Added file: http://bugs.python.org/file11515/bitfields-3.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3547> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3547] Ctypes is confused by bitfields of varying integer types
Changes by Thomas Heller <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11514/bitfields-2.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3547> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3102] ctypes defines global symbols
Thomas Heller <[EMAIL PROTECTED]> added the comment: Is it too late to fix this for Python 2.6 and Python 3.0? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3102> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3900] ctypes: wrong calling convention for _string_at
Thomas Heller <[EMAIL PROTECTED]> added the comment: This is already fixed in SVN, see issue #3554. -- assignee: -> theller nosy: +theller resolution: -> duplicate status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3900> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3547] Ctypes is confused by bitfields of varying integer types
Thomas Heller <[EMAIL PROTECTED]> added the comment: Make this a release blocker so hopefully someone will review it. -- priority: -> release blocker ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3547> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3547] Ctypes is confused by bitfields of varying integer types
Thomas Heller <[EMAIL PROTECTED]> added the comment: Fredrik Lundh schrieb: > Looks fine to me, except for the comment in the test suite. Should > > +# MS compilers do NOT combine c_short and c_int into > +# one field, gcc doesn't. > > perhaps be > > +# MS compilers do NOT combine c_short and c_int into > +# one field, gcc do. Sure. But isn't this correct (or better) english, instead? > Is using explicit tests for MSVC vs. GCC a good idea, btw? What about > other compilers? Can the test be changed to accept either value? Well, MSVC and GCC are the only compilers that I use (and that are tested on the buildbots, afaik). If a cygwin compiled Python, for example, fails this test then of course the test must be changed. Thanks. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3547> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3547] Ctypes is confused by bitfields of varying integer types
Thomas Heller <[EMAIL PROTECTED]> added the comment: Skip Montanaro schrieb: > Looks reasonable, though I'm no ctypes maven. Trivial little nit: > In the comment just before the start of CField_FromDesc it says, > in part: > > * Expects the size, index and offset for the current field in *psize and > * *poffset, stores the total size so far in *psize, the offset for the next > > Note that it identifies three values (size, index, offset) as stored > in two locations (*psize and *poffset). Seems like some sort of > mismatch to me. Unfortunately this is not the only comment that is out of date in the ctypes sources. I wanted to touch as little code as possible in this patch. Thanks. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3547> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3547] Ctypes is confused by bitfields of varying integer types
Thomas Heller <[EMAIL PROTECTED]> added the comment:
Does the following patch fix the test failure with MingW?
Index: cfield.c
===
--- cfield.c(revision 66611)
+++ cfield.c(working copy)
@@ -65,10 +65,10 @@
}
if (bitsize /* this is a bitfield request */
&& *pfield_size /* we have a bitfield open */
-#if defined(MS_WIN32) && !defined(__MINGW32__)
- && dict->size * 8 == *pfield_size /* MSVC */
+#if defined(MS_WIN32)
+ && dict->size * 8 == *pfield_size /* Windows */
#else
- && dict->size * 8 <= *pfield_size /* GCC, MINGW */
+ && dict->size * 8 <= *pfield_size /* GCC */
#endif
&& (*pbitofs + bitsize) <= *pfield_size) {
/* continue bit field */
Also, can you please post the output of the following code snippet?
from ctypes import *
class X(Structure):
_fields_ = [("a", c_short, 4),
("b", c_short, 4),
("c", c_int, 24),
("d", c_short, 4),
("e", c_short, 4),
("f", c_int, 24)]
print X.a
print X.b
print X.c
print X.d
print X.e
print X.f
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3547>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3547] Ctypes is confused by bitfields of varying integer types
Thomas Heller <[EMAIL PROTECTED]> added the comment: Ok, here is an additional patch bitfields-mingw.patch. It fixes the problem reported by rpetrov, and updates the comments. Please review again ;-). The previous patch bitfields-3.patch has already been applied. Added file: http://bugs.python.org/file11619/bitfields-mingw.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3547> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3547] Ctypes is confused by bitfields of varying integer types
Thomas Heller <[EMAIL PROTECTED]> added the comment: Committed as SVN rev 66683 (trunk), 66684 (py3k), and 66685 (release25-maint). -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3547> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
