[issue18060] Updating _fields_ of a derived struct type yields a bad cif
New submission from Lauri Alanko: In Modules/_ctypes/stgdict.c:567 there is a suspicious line: stgdict-length = len; /* ADD ffi_ofs? */ That is, the length field of the stgdict is set to the number of fields in the immediate Structure class, and the number of fields in the parent class (ffi_ofs) is questionably left out. This is wrong. The length field is used in PyCStgDict_clone to copy the ffi_type descriptors for struct elements to a derived struct type. If length is short, not all element types are copied, and the resulting array is not NULL-terminated. So the problem manifests when you inherit from a structure type, update the _fields_ of the inherited type, and then inherit again from the updated type. Even then everything might seem normal, since the elements array is actually not used very much. However, attached is a test case that segfaults at least with debug builds on ARM with the VFP ABI. The non-null-terminated element type array is traversed to find if the structure can be passed in floating point registers, eventually resulting in dereferencing 0xfbfbfbfb. The test program should print out pi. To avoid the hassle of a separate C component, the program abuses the standard atan2 function by pretending it takes a struct of two doubles instead of two separate double parameters. This does not make a difference to the ABI. Fixing the bug is trivial. Just change the line to: stgdict-length = ffi_ofs + len; -- components: ctypes files: t1.py messages: 189992 nosy: lauri.alanko priority: normal severity: normal status: open title: Updating _fields_ of a derived struct type yields a bad cif type: crash versions: Python 3.3 Added file: http://bugs.python.org/file30369/t1.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1298] Support for z/OS and EBCDIC.
Lauri Alanko added the comment: Further comments on the port can be at: http://mail.python.org/pipermail/python-dev/2007-October/074991.html __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1298 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1298] Support for z/OS and EBCDIC.
Lauri Alanko added the comment: How do you measure importance? Z/OS is not important to many people in the world, but to those to whom it is important, it is _very_ important, in a very tangible way. It was certainly important enough for someone to port Python to it. :) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1298 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1298] Support for z/OS and EBCDIC.
Lauri Alanko added the comment: The character set of EBCDIC is a superset of the character set of ASCII. In fact CP1047, the variant used on z/OS, has the same character set as Latin-1. Only the encoding is completely different. As a non-ASCII platform, z/OS is certainly challenging for people used to modern conventions, and that is exactly why a familiar and easy-to-use tool like Python is so valuable there. As for viability, there are some obvious difficulties with Python's handling of source encodings, but as long as you restrict yourself to the ASCII _character set_ in your source code, the vast majority of things seem to work fine with my patch. There are more details in my mail to python-dev, which doesn't seem to have appeared yet. I'm not a subscriber, so it's probably pending moderation somewhere. (I hope The list address accepts e-mail from non-members is still correct information.) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1298 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
