[ python-Bugs-1704156 ] TarFile.addfile() throws a struct.error
Bugs item #1704156, was opened at 2007-04-20 01:21
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704156&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: K. C. Wong (dvusboy)
Assigned to: Nobody/Anonymous (nobody)
Summary: TarFile.addfile() throws a struct.error
Initial Comment:
When adding a file to a TarFile instance using addfile(), if the file paths
(name and arcname) are unicode strings, then a struct.error will the raised.
Python versions prior to 2.5 do not show this behaviour.
Assuming the current directory has a file name 'mac.txt', here is an
interactive session that shows the problem:
Python 2.5 (r25:51908, Apr 18 2007, 19:06:57)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tarfile
>>> t=tarfile.open('test.tar', 'w')
>>> i=t.gettarinfo(u'mac.txt', u'mac.txt')
>>> t.addfile(i, file(u'mac.txt', 'r'))
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/tarfile.py", line 1422, in addfile
self.fileobj.write(tarinfo.tobuf(self.posix))
File "/usr/lib/python2.5/tarfile.py", line 871, in tobuf
buf = struct.pack("%ds" % BLOCKSIZE, "".join(parts))
File "/usr/lib/python2.5/struct.py", line 63, in pack
return o.pack(*args)
struct.error: argument for 's' must be a string
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704156&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1703592 ] have a way to ignore nonexisting locales in locale.setlocale
Feature Requests item #1703592, was opened at 2007-04-19 14:35 Message generated for change (Comment added) made by cjwatson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1703592&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Klose (doko) Assigned to: Martin v. Löwis (loewis) Summary: have a way to ignore nonexisting locales in locale.setlocale Initial Comment: this came up on #ubuntu-devel; Debian and Ubuntu do not generate all libc locales by default, so it is likely that $ LC_ALL=en_US.UTF-8 python -c "import locale; locale.setlocale(locale.LC_ALL, '')" Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/locale.py", line 476, in setlocale return _setlocale(category, locale) locale.Error: unsupported locale setting fails on a system (often experienced ssh'ing into a server system where your current locale doesn't exist). Examples for bug reports in various applications are: https://launchpad.net/bugs/91583 (apt-listchanges) https://launchpad.net/bugs/88638 (pitivi) https://launchpad.net/bugs/81556 (exaile) https://launchpad.net/bugs/90525 (hwdb-client) In C, the result of the setlocale(3) call can be, and usually is ignored, if the locale cannot be set. It is argued that the Python interface for locale.setlocale() should not raise an exception by default, if the locale is missing on the system. That would be an behaviour change of locale.setlocale(), so the original behavour should be kept as an option (introducing an optional third parameter to raise the exception when the locale doesn't exist). Is this an appropriate change, or could another change be suggested? -- Comment By: Colin Watson (cjwatson) Date: 2007-04-20 12:06 Message: Logged In: YES user_id=17056 Originator: NO If this were actually a true error, I'd agree with you, but it isn't. For most programs (that just do locale.setlocale(locale.LC_ALL, '') to switch on internationalisation), it's a warning, not an error; in the common case there is no reason for them to fail. If you still insist that this has to be treated as an error, how about adding locale.enable_i18n or something for the common case that does: try: locale.setlocale(locale.LC_ALL, '') except locale.Error: pass Because, in practice, many programs appear not to bother catching the exception, and because the programmer is typically using an environment with a properly configured locale they won't notice. It's only when you're in an environment such as sshing (with SendEnv) to a remote system that doesn't have your locale configured that you notice that C programs continue to function correctly, Perl programs issue a warning on stderr, but Python programs crash. While noticing errors is a good thing in general, it seems to go a bit far here. -- Comment By: Raymond Hettinger (rhettinger) Date: 2007-04-19 20:33 Message: Logged In: YES user_id=80475 Originator: NO -1 I prefer explicit exception. If needed, it is not hard to catch and ignore the exception. -- Comment By: Martin v. Löwis (loewis) Date: 2007-04-19 18:50 Message: Logged In: YES user_id=21627 Originator: NO Not raising an exception if an operation failed violates the Zen of Python (errors should never pass silently, unless explicitly silenced). So explicit silencing is necessary, but if so, it's easy enough to explicitly catch the exception: try: locale.setlocale(..) except locale.Error: pass If the intention is that all software on Debian works successfully even if the locale is configured incorrectly, then an automated build system should perform all builds in a non-existing locale, and see if anything fails. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1703592&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1704156 ] TarFile.addfile() throws a struct.error
Bugs item #1704156, was opened at 2007-04-20 10:21
Message generated for change (Settings changed) made by gustaebel
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704156&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: K. C. Wong (dvusboy)
>Assigned to: Lars Gustäbel (gustaebel)
Summary: TarFile.addfile() throws a struct.error
Initial Comment:
When adding a file to a TarFile instance using addfile(), if the file paths
(name and arcname) are unicode strings, then a struct.error will the raised.
Python versions prior to 2.5 do not show this behaviour.
Assuming the current directory has a file name 'mac.txt', here is an
interactive session that shows the problem:
Python 2.5 (r25:51908, Apr 18 2007, 19:06:57)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tarfile
>>> t=tarfile.open('test.tar', 'w')
>>> i=t.gettarinfo(u'mac.txt', u'mac.txt')
>>> t.addfile(i, file(u'mac.txt', 'r'))
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/tarfile.py", line 1422, in addfile
self.fileobj.write(tarinfo.tobuf(self.posix))
File "/usr/lib/python2.5/tarfile.py", line 871, in tobuf
buf = struct.pack("%ds" % BLOCKSIZE, "".join(parts))
File "/usr/lib/python2.5/struct.py", line 63, in pack
return o.pack(*args)
struct.error: argument for 's' must be a string
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704156&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1704287 ] must run "make" before "make install"
Bugs item #1704287, was opened at 2007-04-20 07:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704287&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joseph VanAndel (vanandel) Assigned to: Nobody/Anonymous (nobody) Summary: must run "make" before "make install" Initial Comment: "make install" fails unless you've already run "make". Not a show-stopper, but specifying the correct dependencies for "make install" would force everything to be built before it was installed. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704287&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1703952 ] ctypes: problem with large integers
Bugs item #1703952, was opened at 2007-04-19 23:51
Message generated for change (Comment added) made by theller
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1703952&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Alexander Belopolsky (belopolsky)
>Assigned to: Thomas Heller (theller)
Summary: ctypes: problem with large integers
Initial Comment:
Python 2.5 (r25:51908, Nov 24 2006, 11:03:50)
[GCC 3.4.4 20050721 (Red Hat 3.4.4-2)] on linux2
>>> from ctypes import *
>>> c_int(2**31).value
-2147483648
>>> c_long(2**32-1).value
-1
In a 64-bit build, the situation is even worse:
>>> c_int(int(2**32)).value
0
>>> c_int(2**32).value
0
Another way to see the problem:
>>> c = CDLL(None)
>>> c.printf("%d\n", 2**32)
0
2
--
>Comment By: Thomas Heller (theller)
Date: 2007-04-20 20:55
Message:
Logged In: YES
user_id=11105
Originator: NO
This works as designed. ctypes intentionally does no overflow checking
when using the c_int, c_uint, and related integer types. Instead, only the
available bits are used - just as in C.
Closing as invalid (sorry).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1703952&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1704156 ] TarFile.addfile() throws a struct.error
Bugs item #1704156, was opened at 2007-04-20 10:21
Message generated for change (Comment added) made by gustaebel
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704156&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: K. C. Wong (dvusboy)
Assigned to: Lars Gustäbel (gustaebel)
Summary: TarFile.addfile() throws a struct.error
Initial Comment:
When adding a file to a TarFile instance using addfile(), if the file paths
(name and arcname) are unicode strings, then a struct.error will the raised.
Python versions prior to 2.5 do not show this behaviour.
Assuming the current directory has a file name 'mac.txt', here is an
interactive session that shows the problem:
Python 2.5 (r25:51908, Apr 18 2007, 19:06:57)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tarfile
>>> t=tarfile.open('test.tar', 'w')
>>> i=t.gettarinfo(u'mac.txt', u'mac.txt')
>>> t.addfile(i, file(u'mac.txt', 'r'))
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/tarfile.py", line 1422, in addfile
self.fileobj.write(tarinfo.tobuf(self.posix))
File "/usr/lib/python2.5/tarfile.py", line 871, in tobuf
buf = struct.pack("%ds" % BLOCKSIZE, "".join(parts))
File "/usr/lib/python2.5/struct.py", line 63, in pack
return o.pack(*args)
struct.error: argument for 's' must be a string
--
>Comment By: Lars Gustäbel (gustaebel)
Date: 2007-04-20 21:25
Message:
Logged In: YES
user_id=642936
Originator: NO
tarfile.py was never guaranteed to work correctly with unicode filenames.
The fact that this works with Python < 2.5 is purely accidental.
You can work around this (sticking to your example):
i = t.gettarinfo(u'mac.txt', 'mac.txt')
or:
i = t.gettarinfo('mac.txt')
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704156&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1703952 ] ctypes: problem with large integers
Bugs item #1703952, was opened at 2007-04-19 17:51
Message generated for change (Comment added) made by belopolsky
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1703952&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
>Status: Open
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Alexander Belopolsky (belopolsky)
Assigned to: Thomas Heller (theller)
Summary: ctypes: problem with large integers
Initial Comment:
Python 2.5 (r25:51908, Nov 24 2006, 11:03:50)
[GCC 3.4.4 20050721 (Red Hat 3.4.4-2)] on linux2
>>> from ctypes import *
>>> c_int(2**31).value
-2147483648
>>> c_long(2**32-1).value
-1
In a 64-bit build, the situation is even worse:
>>> c_int(int(2**32)).value
0
>>> c_int(2**32).value
0
Another way to see the problem:
>>> c = CDLL(None)
>>> c.printf("%d\n", 2**32)
0
2
--
>Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-20 15:37
Message:
Logged In: YES
user_id=835142
Originator: YES
An issue remains with the implicit conversion:
On a 64-bit platform (sizeof(long)=64):
>>> c.printf("%d\n",1<<64)
Traceback (most recent call last):
File "", line 1, in
ctypes.ArgumentError: argument 2: : long
int too long to convert
so it does do overflow checking, but
>>> c.printf("%d\n",(1<<64)-1)
-1
3
>>> c.printf("%d\n",(1<<32))
0
2
--
Comment By: Thomas Heller (theller)
Date: 2007-04-20 14:55
Message:
Logged In: YES
user_id=11105
Originator: NO
This works as designed. ctypes intentionally does no overflow checking
when using the c_int, c_uint, and related integer types. Instead, only the
available bits are used - just as in C.
Closing as invalid (sorry).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1703952&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1701409 ] Segfault in c_char_p of ctypes
Bugs item #1701409, was opened at 2007-04-16 12:45
Message generated for change (Comment added) made by theller
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1701409&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: sebastien Martini (seb_martini)
Assigned to: Thomas Heller (theller)
Summary: Segfault in c_char_p of ctypes
Initial Comment:
Hi,
I experienced a segmentation fault (when providing a wrong argument type to
c_char_p) in the ctypes module under Linux and with the version 2.5 .
sundae:~$ python
Python 2.5.1c1 (release25-maint, Apr 6 2007, 22:02:36)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import *
>>> c_char_p(42)
zsh: segmentation fault (core dumped) python
sundae:~$
Regards,
Sebastien Martini
--
>Comment By: Thomas Heller (theller)
Date: 2007-04-20 21:52
Message:
Logged In: YES
user_id=11105
Originator: NO
belopolsky: _objects is only set when the c_char_p instance is created in
the way you described. It will not be set if the instance is modified by a
foreign function call, so this is not robust.
nnorwitz: Sure there are many ways to crash Python with ctypes, but
printing c_char_p(42) should not carsh, IMO.
I believe the best strategy would be to behave this way on Windows where
the check for a valid string pointer can be made:
>>> c_char_p(42)
c_char_p(0x2A)
>>> c_char("foo")
c_char('foo')
>>>
and this way on other systems:
>>> c_char_p(42)
c_char_p(0x2A)
>>> c_char_p("foo")
c_char_p(0x2A7F3B)
>>>
The attached patch fixes this for c_char_p, a similar patch should be
applied to c_wchar_p.
File Added: c_char_p.patch
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-19 22:47
Message:
Logged In: YES
user_id=835142
Originator: NO
It is easy to distinguish between a c_char_p that is created from a python
string from one that is created from a python int: the former has an
_objects attribute set to a string:
>>> x,y = map(c_char_p, ('abc',42))
>>> (x._objects,y._objects)
('abc', None)
It may be reasonable to give up a "nice" repr for the cases where c_char_p
is not known to point into a python string. You can still keep "nice" str,
so users can still enjoy a crash by printing c_char_p(42). :-)
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-04-19 08:58
Message:
Logged In: YES
user_id=33168
Originator: NO
> Do other platforms have a function that can do this check?
There's no platform independent way to do this.
I don't know anything about ctypes, but what might be a way to handle this
is providing a way to convert an integer into a pointer (like a void*).
Then all these routines could accept this void* type that you would define,
but not accept a raw integer. That means people would still have access to
do the same thing they can currently do, but it would be clearer that they
are playing with fire by converting any int into a pointer.
There are so many ways to use ctypes to crash, I'm not sure if this is
worth fixing, except perhaps in the docs to point out the issues.
--
Comment By: Thomas Heller (theller)
Date: 2007-04-18 21:20
Message:
Logged In: YES
user_id=11105
Originator: NO
This is a difficult issue. The integer (which is interpreted as address)
is allowed because some libraries use 'char *' pointers initialized to
small, invalid addresses for special purposes.
On windows, printing a c_char_p(42) does not crash, it raises a ValueError
instead:
>>> from ctypes import *
>>> c_char_p(42)
Traceback (most recent call last):
File "", line 1, in
ValueError: invalid string pointer 0x00B20B48
>>>
Windows does this by checking if there is a valid string at the address
(see Modules/_ctypes/cfield.c, line 1366) by calling the IsBadStringPointer
api function. Do other platforms have a function that can do this check?
If not, I'm afraid we would have to give up on the very convenient repr of
'normal' c_char_p instances:
>>> c_char_p("foo bar")
c_char_p('foo bar')
>>>
and only print the address (at least on non-windows).
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-04-18 09:37
Message:
Logged In: YES
user_id=33168
Originator: NO
Thanks for the bug report Sebastien.
This bug occurs in 2.5 and in the trunk, so it's not a regression.
Thomas, could you take a look? Integers are specifically allowed here
(floats are not). Th
[ python-Feature Requests-1703592 ] have a way to ignore nonexisting locales in locale.setlocale
Feature Requests item #1703592, was opened at 2007-04-19 15:35 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1703592&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Klose (doko) Assigned to: Martin v. Löwis (loewis) Summary: have a way to ignore nonexisting locales in locale.setlocale Initial Comment: this came up on #ubuntu-devel; Debian and Ubuntu do not generate all libc locales by default, so it is likely that $ LC_ALL=en_US.UTF-8 python -c "import locale; locale.setlocale(locale.LC_ALL, '')" Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/locale.py", line 476, in setlocale return _setlocale(category, locale) locale.Error: unsupported locale setting fails on a system (often experienced ssh'ing into a server system where your current locale doesn't exist). Examples for bug reports in various applications are: https://launchpad.net/bugs/91583 (apt-listchanges) https://launchpad.net/bugs/88638 (pitivi) https://launchpad.net/bugs/81556 (exaile) https://launchpad.net/bugs/90525 (hwdb-client) In C, the result of the setlocale(3) call can be, and usually is ignored, if the locale cannot be set. It is argued that the Python interface for locale.setlocale() should not raise an exception by default, if the locale is missing on the system. That would be an behaviour change of locale.setlocale(), so the original behavour should be kept as an option (introducing an optional third parameter to raise the exception when the locale doesn't exist). Is this an appropriate change, or could another change be suggested? -- >Comment By: Martin v. Löwis (loewis) Date: 2007-04-20 21:59 Message: Logged In: YES user_id=21627 Originator: NO How can you say it's not an error? The function does not achieve what it attempts to. Adding another function with a different semantics is fine to me, although I doubt it helps: the existing code calls setlocale, not that other function. -- Comment By: Colin Watson (cjwatson) Date: 2007-04-20 13:06 Message: Logged In: YES user_id=17056 Originator: NO If this were actually a true error, I'd agree with you, but it isn't. For most programs (that just do locale.setlocale(locale.LC_ALL, '') to switch on internationalisation), it's a warning, not an error; in the common case there is no reason for them to fail. If you still insist that this has to be treated as an error, how about adding locale.enable_i18n or something for the common case that does: try: locale.setlocale(locale.LC_ALL, '') except locale.Error: pass Because, in practice, many programs appear not to bother catching the exception, and because the programmer is typically using an environment with a properly configured locale they won't notice. It's only when you're in an environment such as sshing (with SendEnv) to a remote system that doesn't have your locale configured that you notice that C programs continue to function correctly, Perl programs issue a warning on stderr, but Python programs crash. While noticing errors is a good thing in general, it seems to go a bit far here. -- Comment By: Raymond Hettinger (rhettinger) Date: 2007-04-19 21:33 Message: Logged In: YES user_id=80475 Originator: NO -1 I prefer explicit exception. If needed, it is not hard to catch and ignore the exception. -- Comment By: Martin v. Löwis (loewis) Date: 2007-04-19 19:50 Message: Logged In: YES user_id=21627 Originator: NO Not raising an exception if an operation failed violates the Zen of Python (errors should never pass silently, unless explicitly silenced). So explicit silencing is necessary, but if so, it's easy enough to explicitly catch the exception: try: locale.setlocale(..) except locale.Error: pass If the intention is that all software on Debian works successfully even if the locale is configured incorrectly, then an automated build system should perform all builds in a non-existing locale, and see if anything fails. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1703592&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1701409 ] Segfault in c_char_p of ctypes
Bugs item #1701409, was opened at 2007-04-16 06:45
Message generated for change (Comment added) made by belopolsky
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1701409&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: sebastien Martini (seb_martini)
Assigned to: Thomas Heller (theller)
Summary: Segfault in c_char_p of ctypes
Initial Comment:
Hi,
I experienced a segmentation fault (when providing a wrong argument type to
c_char_p) in the ctypes module under Linux and with the version 2.5 .
sundae:~$ python
Python 2.5.1c1 (release25-maint, Apr 6 2007, 22:02:36)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import *
>>> c_char_p(42)
zsh: segmentation fault (core dumped) python
sundae:~$
Regards,
Sebastien Martini
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-20 16:42
Message:
Logged In: YES
user_id=835142
Originator: NO
theller: [_objects] will not be set if the instance is modified by a
foreign function call, so this is not robust.
I thought about this before making my suggestion. I believe people will
be less surprized if objects returned from an ffi call print with funny
numbers than getting c_char_p(N) after entering c_char_p("abc").
A few comments on the patch:
1. Since c_void_p is printed in decimal, shouldn't c_char_p be treated the
same? If hexadecimal is prefered, maybe c_void_p should be changed.
2. Currently c_char_p(0) is printed as c_char_p(None), but the patch will
change that to c_char_p(0).
--
Comment By: Thomas Heller (theller)
Date: 2007-04-20 15:52
Message:
Logged In: YES
user_id=11105
Originator: NO
belopolsky: _objects is only set when the c_char_p instance is created in
the way you described. It will not be set if the instance is modified by a
foreign function call, so this is not robust.
nnorwitz: Sure there are many ways to crash Python with ctypes, but
printing c_char_p(42) should not carsh, IMO.
I believe the best strategy would be to behave this way on Windows where
the check for a valid string pointer can be made:
>>> c_char_p(42)
c_char_p(0x2A)
>>> c_char("foo")
c_char('foo')
>>>
and this way on other systems:
>>> c_char_p(42)
c_char_p(0x2A)
>>> c_char_p("foo")
c_char_p(0x2A7F3B)
>>>
The attached patch fixes this for c_char_p, a similar patch should be
applied to c_wchar_p.
File Added: c_char_p.patch
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-19 16:47
Message:
Logged In: YES
user_id=835142
Originator: NO
It is easy to distinguish between a c_char_p that is created from a python
string from one that is created from a python int: the former has an
_objects attribute set to a string:
>>> x,y = map(c_char_p, ('abc',42))
>>> (x._objects,y._objects)
('abc', None)
It may be reasonable to give up a "nice" repr for the cases where c_char_p
is not known to point into a python string. You can still keep "nice" str,
so users can still enjoy a crash by printing c_char_p(42). :-)
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-04-19 02:58
Message:
Logged In: YES
user_id=33168
Originator: NO
> Do other platforms have a function that can do this check?
There's no platform independent way to do this.
I don't know anything about ctypes, but what might be a way to handle this
is providing a way to convert an integer into a pointer (like a void*).
Then all these routines could accept this void* type that you would define,
but not accept a raw integer. That means people would still have access to
do the same thing they can currently do, but it would be clearer that they
are playing with fire by converting any int into a pointer.
There are so many ways to use ctypes to crash, I'm not sure if this is
worth fixing, except perhaps in the docs to point out the issues.
--
Comment By: Thomas Heller (theller)
Date: 2007-04-18 15:20
Message:
Logged In: YES
user_id=11105
Originator: NO
This is a difficult issue. The integer (which is interpreted as address)
is allowed because some libraries use 'char *' pointers initialized to
small, invalid addresses for special purposes.
On windows, printing a c_char_p(42) does not crash, it raises a ValueError
instead:
>>> from ctypes import *
>>> c_char_p(42)
Traceback (most recent call last):
File "", line 1, in
ValueError: invalid string pointer 0x00B20B48
>>>
Windows
[ python-Bugs-1704156 ] TarFile.addfile() throws a struct.error
Bugs item #1704156, was opened at 2007-04-20 01:21
Message generated for change (Comment added) made by dvusboy
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704156&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: K. C. Wong (dvusboy)
Assigned to: Lars Gustäbel (gustaebel)
Summary: TarFile.addfile() throws a struct.error
Initial Comment:
When adding a file to a TarFile instance using addfile(), if the file paths
(name and arcname) are unicode strings, then a struct.error will the raised.
Python versions prior to 2.5 do not show this behaviour.
Assuming the current directory has a file name 'mac.txt', here is an
interactive session that shows the problem:
Python 2.5 (r25:51908, Apr 18 2007, 19:06:57)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tarfile
>>> t=tarfile.open('test.tar', 'w')
>>> i=t.gettarinfo(u'mac.txt', u'mac.txt')
>>> t.addfile(i, file(u'mac.txt', 'r'))
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/tarfile.py", line 1422, in addfile
self.fileobj.write(tarinfo.tobuf(self.posix))
File "/usr/lib/python2.5/tarfile.py", line 871, in tobuf
buf = struct.pack("%ds" % BLOCKSIZE, "".join(parts))
File "/usr/lib/python2.5/struct.py", line 63, in pack
return o.pack(*args)
struct.error: argument for 's' must be a string
--
>Comment By: K. C. Wong (dvusboy)
Date: 2007-04-20 21:54
Message:
Logged In: YES
user_id=414175
Originator: YES
I see the work around, and I have already implemented similar workarounds
in my code. However, I have 2 problem with this response:
1. The behaviour changed. As the documentation did not explicitly say
tarfile does not support unicode file paths, and it worked prior to 2.5,
then I would say breaking that behaviour at the least calls for a
documentation update.
2. The error message stamps from struct failing to pack a unicode string.
First of all, I did not grasp the subtle message of it being a unicode
string as opposed to a non-unicode string. You see, I actually did not
expect unicode string in the first place, it was a by-product of TEXT_DATA
from a DOM tree. I can understand why struct.pack() throws (because no
explicit encoding scheme was specified) but it was so cryptic with regard
to tarfile itself, that I had to modify tarfile to track down the reason
for the exception.
In short, I would prefer the owner of tarfile to make an explicit support
or not-supported call on unicode file path, document said decision and make
more reasonable attempt in presenting releavant exceptions.
Thank you for looking into this.
--
Comment By: Lars Gustäbel (gustaebel)
Date: 2007-04-20 12:25
Message:
Logged In: YES
user_id=642936
Originator: NO
tarfile.py was never guaranteed to work correctly with unicode filenames.
The fact that this works with Python < 2.5 is purely accidental.
You can work around this (sticking to your example):
i = t.gettarinfo(u'mac.txt', 'mac.txt')
or:
i = t.gettarinfo('mac.txt')
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704156&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
