[issue9116] test_capi.test_no_FatalError_infinite_loop crash on Windows

[Georg Brandl]

Changes by Georg Brandl :


--
priority: deferred blocker -> release blocker

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8959] WINFUNCTYPE wrapped ctypes callbacks not functioning correctly in Python 2.7

[Georg Brandl]

Changes by Georg Brandl :


--
priority: deferred blocker -> release blocker

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9437] can't build extensions with non-default ldflags (e.g. -m32)

[Georg Brandl]

Changes by Georg Brandl :


--
priority: deferred blocker -> release blocker

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9662] ctypes not building under OS X because of ffi_closure_free not being defined early enough

[Georg Brandl]

Changes by Georg Brandl :


--
priority: deferred blocker -> release blocker

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8611] Python3 doesn't support locale different than utf8 and an non-ASCII path (POSIX)

[Georg Brandl]

Changes by Georg Brandl :


--
priority: deferred blocker -> release blocker

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7418] hashlib : the names of the different hash algorithms

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Implemented in py3k r84554.

--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4499] redefinition of TILDE macro on AIX platform

[Sébastien Sablé]

Sébastien Sablé  added the comment:

I can confirm that this problem is still present with Python 3.1.2 on AIX 6.1. 
This is just a compilation warning, but the patch in
msg110771 correctly cleans it.

xlc_r -c  -DNDEBUG -O  -I. -IInclude -I./Include 
-I/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/include
 
-I/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/include/ncurses
 
-I/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/include
  -DPy_BUILD_CORE -o Parser/acceler.o Parser/acceler.c
"Include/token.h", line 42.9: 1506-236 (W) Macro name TILDE has been redefined.
"Include/token.h", line 42.9: 1506-358 (I) "TILDE" is defined on line 270 of 
/usr/include/sys/ioctl.h.

--
nosy: +sable

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9778] Make hash values the same width as a pointer (or Py_ssize_t)

[Mark Dickinson]

Mark Dickinson  added the comment:

> ... change all hash values to be of Py_ssize_t values rather than C longs ...

Yes, please!  (Provided this change can go in before 3.2.)  For the numeric 
types at least, this should be a straightforward adjustment.

And while we're at it, we could clean up some of the undefined behaviour from 
integer overflow that's in the current hash functions (tuple.__hash__, for 
example).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6768] asyncore file_wrapper leaking file descriptors?

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

Closing out because no response has been provided by the OP.

--
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8684] improvements to sched.py

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

Josiah are you still interested in this?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9781] Dead link

[Arialdo Martini]

New submission from Arialdo Martini :

In the Italian version of the Official  Turorial, the link to  Python Bug 
Tracker is dead.

--
assignee: d...@python
components: Documentation
messages: 115698
nosy: Arialdo.Martini, d...@python
priority: normal
severity: normal
status: open
title: Dead link
type: resource usage

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9781] Dead link in Italian Tutorial

[Arialdo Martini]

Changes by Arialdo Martini :


--
title: Dead link -> Dead link in Italian Tutorial

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9782] _multiprocessing.c warnings under 64-bit Windows

[Antoine Pitrou]

New submission from Antoine Pitrou :

There are various warnings when compiling the _multiprocessing extension in 
64-bit mode under Windows. Many seem related to the fact that read() and 
friends under Windows take "int" size arguments rather than "size_t".

20>-- Build started: Project: _multiprocessing, Configuration: Release x64 
--
20>Compiling...
20>multiprocessing.c
20>win32_functions.c
20>socket_connection.c
20>..\Modules\_multiprocessing\socket_connection.c(32) : warning C4267: 
'function' : conversion from 'size_t' to 'int', possible loss of data
20>..\Modules\_multiprocessing\socket_connection.c(54) : warning C4267: 
'function' : conversion from 'size_t' to 'int', possible loss of data
20>..\Modules\_multiprocessing\socket_connection.c(126) : warning C4244: '=' : 
conversion from 'Py_ssize_t' to 'int', possible loss of data
20>..\Modules\_multiprocessing\socket_connection.c(137) : warning C4244: '=' : 
conversion from 'Py_ssize_t' to 'int', possible loss of data
20>..\Modules\_multiprocessing\socket_connection.c(145) : warning C4244: '=' : 
conversion from 'Py_ssize_t' to 'int', possible loss of data
20>z:\py3k\__svn__\modules\_multiprocessing\connection.h(139) : warning C4244: 
'=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>z:\py3k\__svn__\modules\_multiprocessing\connection.h(183) : warning C4244: 
'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>z:\py3k\__svn__\modules\_multiprocessing\connection.h(237) : warning C4244: 
'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>z:\py3k\__svn__\modules\_multiprocessing\connection.h(285) : warning C4244: 
'=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>z:\py3k\__svn__\modules\_multiprocessing\connection.h(323) : warning C4244: 
'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>semaphore.c
20>pipe_connection.c
20>..\Modules\_multiprocessing\pipe_connection.c(24) : warning C4267: 
'function' : conversion from 'size_t' to 'DWORD', possible loss of data
20>..\Modules\_multiprocessing\pipe_connection.c(50) : warning C4267: 
'function' : conversion from 'size_t' to 'DWORD', possible loss of data
20>z:\py3k\__svn__\modules\_multiprocessing\connection.h(139) : warning C4244: 
'=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>z:\py3k\__svn__\modules\_multiprocessing\connection.h(183) : warning C4244: 
'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>z:\py3k\__svn__\modules\_multiprocessing\connection.h(237) : warning C4244: 
'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>z:\py3k\__svn__\modules\_multiprocessing\connection.h(285) : warning C4244: 
'=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>z:\py3k\__svn__\modules\_multiprocessing\connection.h(323) : warning C4244: 
'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>Linking...
20>   Creating library Z:\py3k\__svn__\PCbuild\\amd64\\_multiprocessing.lib and 
object Z:\py3k\__svn__\PCbuild\\amd64\\_multiprocessing.exp
20>Generating code
20>Finished generating code
20>Build log was saved at 
"file://Z:\py3k\__svn__\PCbuild\x64-temp-Release\_multiprocessing\BuildLog.htm"
20>_multiprocessing - 0 error(s), 17 warning(s)

--
components: Extension Modules, Windows
messages: 115699
nosy: brian.curtin, jnoller, pitrou, tim.golden
priority: normal
severity: normal
stage: needs patch
status: open
title: _multiprocessing.c warnings under 64-bit Windows
type: compile error
versions: Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9783] _elementtree.c warnings under 64-bit Windows

[Antoine Pitrou]

New submission from Antoine Pitrou :

Some of these warnings could be serious (e.g. the one where the 64-bit "self" 
is converted to a 32-bit "long"):

13>..\Modules\_elementtree.c(696) : warning C4244: 'function' : conversion from 
'Py_uintptr_t' to 'long', possible loss of data
13>..\Modules\_elementtree.c(1239) : warning C4244: '=' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
13>..\Modules\_elementtree.c(1372) : warning C4244: 'function' : conversion 
from 'Py_ssize_t' to 'int', possible loss of data
13>..\Modules\_elementtree.c(1414) : warning C4244: '+=' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
13>..\Modules\_elementtree.c(2076) : warning C4267: 'initializing' : conversion 
from 'size_t' to 'int', possible loss of data
13>..\Modules\_elementtree.c(2663) : warning C4244: 'function' : conversion 
from 'Py_ssize_t' to 'int', possible loss of data

--
components: Extension Modules, Windows
messages: 115700
nosy: effbot, flox, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: _elementtree.c warnings under 64-bit Windows
type: compile error
versions: Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9784] _msi.c warnings under 64-bit Windows

[Antoine Pitrou]

New submission from Antoine Pitrou :

I'm posting this in case it is a sign of a problem. Apparently some variable 
named "hf" is an INT_PTR used as an int (according to Visual Studio), but "hf" 
doesn't seem to be defined or declared in _msi.c at all.

12>..\PC\_msi.c(66) : warning C4244: 'function' : conversion from 'INT_PTR' to 
'int', possible loss of data
12>..\PC\_msi.c(74) : warning C4244: 'function' : conversion from 'INT_PTR' to 
'int', possible loss of data
12>..\PC\_msi.c(82) : warning C4244: 'function' : conversion from 'INT_PTR' to 
'int', possible loss of data
12>..\PC\_msi.c(90) : warning C4244: 'function' : conversion from 'INT_PTR' to 
'int', possible loss of data

--
components: Extension Modules
messages: 115701
nosy: loewis, pitrou
priority: normal
severity: normal
status: open
title: _msi.c warnings under 64-bit Windows
type: compile error
versions: Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9785] _PyUnicode_New(), throw and memory problem

[Trigve Siver]

New submission from Trigve Siver :

I'm using C++ with python embeding.
I'm creating a couple of unicode objects and then some
exception is thrown. While handling exception I create othet unicode objects. 
Then when creating some unicode object crash occurs. The problem is in 
_PyUnicode_New():325 on line (1):

if (free_list) {
unicode = free_list; /*<- (1)*/
free_list = *(PyUnicodeObject **)unicode;

In statement "unicode = free_list;" "unicode" pointer is bad pointer, in fact 
it's address is 5 bytes "lower" (i.e. should be 0x030bc3ff but is 0x030bc3fa).

It looks like this only happens when exception is thrown.

When python exception is set I throw C++ exception to signal C++ code that py 
exception was set. Next in C++ exception handler I format the python exception 
using some python unicode objects and then the problem occurs.
Without the C++ throw (Only python exception formatting) it looks like 
everything is working OK.

I'm using python 3.1.2 on Vista with MSVS 2010. I've also tried python 3.2a2 
but it was the same.

I've tried to isolate the problem in some simple example but haven't been 
successful yet.

--
components: Library (Lib)
messages: 115702
nosy: Trigve.Siver
priority: normal
severity: normal
status: open
title: _PyUnicode_New(), throw and memory problem
type: crash
versions: Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue941346] AIX shared library fix

[Sébastien Sablé]

Sébastien Sablé  added the comment:

Hi,

I have updated the patch and adapted it for Python 3.1.2:

* this time ld_so_aix is moved to ld_so_aix.in which is converted to ld_so_aix 
by 'configure' so that it has the right version number for the python library

* there are no more warnings for 'Duplicate symbol': I changed build_ext.py to 
not link extensions with libpython since the symbols are already defined by 
python.exp

* I made a modification to ld_so_aix specifically for Python 3 as according to 
pep-3121 the entry function has been renamed from init to 
PyInit_

I will provide another patch for Python 2.7 (nearly the same, but without the 
modification needed by pep-3121).
I also attach the build log for Python 3.1.2 without and with this patch.

regards

--
Added file: http://bugs.python.org/file18762/Python-3.1.2_shared_AIX.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue941346] AIX shared library fix

[Sébastien Sablé]

Changes by Sébastien Sablé :


Added file: 
http://bugs.python.org/file18763/python312_AIX61_static_nopatch.txt.gz

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue941346] AIX shared library fix

[Sébastien Sablé]

Changes by Sébastien Sablé :


Added file: 
http://bugs.python.org/file18764/python312_AIX61_static_patch_shared.txt.gz

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue941346] AIX shared library fix

[Sébastien Sablé]

Changes by Sébastien Sablé :


Added file: 
http://bugs.python.org/file18765/python312_AIX61_shared_patch_shared.txt.gz

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue941346] AIX shared library fix

[Sébastien Sablé]

Changes by Sébastien Sablé :


--
versions: +Python 2.6, Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9781] Dead link in Italian Tutorial

[Benjamin Peterson]

Benjamin Peterson  added the comment:

We don't maintain an Italian version of the tutorial. You'll have to contact 
its maintainer.

--
nosy: +benjamin.peterson
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9129] DoS smtpd module vulnerability

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

This is already in 2.6 branch.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4026] fcntl extension fails to build on AIX 6.1

[Sébastien Sablé]

Sébastien Sablé  added the comment:

Here is the version of the patch for Python 2.7.
I had to change AC_TRY_COMPILE to AC_COMPILE_IFELSE and AC_TRY_LINK to 
AC_LINK_IFELSE.

The syntax in configure.in is the same between Python 2.7 and the trunk. It is 
also the same between Python 2.6.6 and Python 3.1.2.

So this patch can be applied on the trunk and the patch 
Python-2.6.6_flock_AIX.diff can be applied on Python 3.1.2.

--
Added file: http://bugs.python.org/file18766/Python-2.7_flock_AIX.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue941346] AIX shared library fix

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Thank you. For the record, here is the patch adapted for 3.2 development 
branch. It looks ok to me.

--
stage: unit test needed -> patch review
versions: +Python 3.2 -Python 2.6
Added file: http://bugs.python.org/file18767/aix32.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue941346] AIX shared library fix

[Sébastien Sablé]

Sébastien Sablé  added the comment:

Here is the patch for Python 2.7.

The only difference compared to Python 3.1.2 is that we don't rename 
init to PyInit_.

--
versions: +Python 2.6 -Python 3.2
Added file: http://bugs.python.org/file18768/Python-2.7_shared_AIX.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue941346] AIX shared library fix

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> * there are no more warnings for 'Duplicate symbol': I changed
> build_ext.py to not link extensions with libpython since the symbols
> are already defined by python.exp

Could this affect building extensions with gcc under AIX? Or does gcc delegate 
to the AIX linker?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9780] fill character cannot be '{'

[Eric Smith]

Eric Smith  added the comment:

Sorry to respond late.

The reason for this is that the parsing of the string (as delimited by "{" and 
"}") happens before the results are then interpreted as format specifiers. 
There's no way around it, short of the parser understanding every object's 
formatting language, which is of course not possible. It could be special cased 
for string, int, and float format specifiers, but that doesn't make much sense.

I think the doc change is good.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1731717] race condition in subprocess module

[Jonas H.]

Changes by Jonas H. :


--
nosy: +jonash

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4026] fcntl extension fails to build on AIX 6.1

[Michael Haubenwallner]

Michael Haubenwallner  added the comment:

While I've not tested these patches myself, I do think there still is an 
unhandled case: building a 64bit python.
As libbsd.a contains 32bit objects only, there is no 64bit flock().
So AC_CHECK_LIB(bsd,flock) may still fail, which should result in have_flock=no 
then.
Thank you!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9607] Test file 'test_keyword.py' submission for use with keyword.py

[Greg Malcolm]

Changes by Greg Malcolm :


Removed file: http://bugs.python.org/file18537/test_keyword.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9607] Test file 'test_keyword.py' submission for use with keyword.py

[Greg Malcolm]

Greg Malcolm  added the comment:

Thanks for the feedback David! I've replaced the old patch with a new version 
that uses Popen/sys.executable as suggested.

- Greg

--
Added file: http://bugs.python.org/file18769/test_keyword_v2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9324] signal.signal(bogus_signal, handler) segfaults on Windows

[Brian Curtin]

Brian Curtin  added the comment:

Checked in the suggested fixes in r84556 (py3k), r84557 (release27-maint), and 
r84558 (release27-maint).

--
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9785] _PyUnicode_New(), throw and memory problem

[Trigve Siver]

Trigve Siver  added the comment:

I've tried to examine it in more depth.

Setting the python exception isn't necessary, only throwing the C++ exception 
is needed for demonstrating the problem.

Also sometimes the address is 6 bytes "lower" than should be.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8956] Incorrect ValueError message for subprocess.Popen.send_signal() on Windows

[Brian Curtin]

Brian Curtin  added the comment:

Fixed in r84559 (py3k) and r84560 (release27-maint).

--
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8372] socket: Buffer overrun while reading unterminated AF_UNIX addresses

[David Watson]

David Watson  added the comment:

> baikie, coming back to your original message: what precisely makes you 
> believe that sun_path does not need to be null-terminated on Linux?

That's the way I demonstrated the bug - the only way to bind to a
108-byte path is to pass it without null termination, because
Linux will not accept an oversized sockaddr_un structure (e.g. a
108-byte path plus null terminator).  Also, unless it's on OS/2,
Python's existing code never includes the null terminator in the
address size it passes to the system call, so a correctly-
behaving OS should never see it.

However, it does now occur to me that a replacement libc
implementation for Linux could try to do something with sun_path
during the call and assume it's null-terminated even though the
kernel doesn't, so it may be best to keep the null termination
requirement after all.  In that case, there would be no way to
test for the bug from within Python, so the test problems would
be somewhat moot (although the test code could still be used by
changing UNIX_PATH_MAX from 108 to 107).

Attaching four-space-indent versions of the original patches (for
2.x and 3.x), and tests incorporating Antoine's use of
assertRaisesRegexp.

--
Added file: http://bugs.python.org/file18770/linux-pass-unterminated-4spc.diff
Added file: http://bugs.python.org/file18771/return-unterminated-2.x-4spc.diff
Added file: http://bugs.python.org/file18772/return-unterminated-3.x-4spc.diff
Added file: http://bugs.python.org/file18773/addrlen-2.x-4spc.diff
Added file: http://bugs.python.org/file18774/addrlen-3.x-4spc.diff
Added file: http://bugs.python.org/file18775/test-2.x-new.diff
Added file: http://bugs.python.org/file18776/test-3.x-new.diff

___
Python tracker 

___Allow AF_UNIX pathnames up to the maximum 108 bytes on Linux,
since it does not require sun_path to be null terminated.

diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c
--- a/Modules/socketmodule.c
+++ b/Modules/socketmodule.c
@@ -1187,27 +1187,16 @@ getsockaddrarg(PySocketSockObject *s, Py
 
 addr = (struct sockaddr_un*)addr_ret;
 #ifdef linux
-if (len > 0 && path[0] == 0) {
-/* Linux abstract namespace extension */
-if (len > sizeof addr->sun_path) {
-PyErr_SetString(socket_error,
-"AF_UNIX path too long");
-return 0;
-}
-}
-else
-#endif /* linux */
-{
-/* regular NULL-terminated string */
-if (len >= sizeof addr->sun_path) {
-PyErr_SetString(socket_error,
-"AF_UNIX path too long");
-return 0;
-}
-addr->sun_path[len] = 0;
+if (len > sizeof(addr->sun_path)) {
+#else
+if (len >= sizeof(addr->sun_path)) {
+#endif
+PyErr_SetString(socket_error, "AF_UNIX path too long");
+return 0;
 }
 addr->sun_family = s->sock_family;
 memcpy(addr->sun_path, path, len);
+memset(addr->sun_path + len, 0, sizeof(addr->sun_path) - len);
 #if defined(PYOS_OS2)
 *len_ret = sizeof(*addr);
 #else
When parsing sockaddr_un structures returned by accept(), etc.,
only examine bytes up to supplied addrlen and do not require null
termination.

diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c
--- a/Modules/socketmodule.c
+++ b/Modules/socketmodule.c
@@ -998,19 +998,22 @@ makesockaddr(int sockfd, struct sockaddr
 #if defined(AF_UNIX)
 case AF_UNIX:
 {
+Py_ssize_t len, splen;
 struct sockaddr_un *a = (struct sockaddr_un *) addr;
+splen = addrlen - offsetof(struct sockaddr_un, sun_path);
 #ifdef linux
-if (a->sun_path[0] == 0) {  /* Linux abstract namespace */
-addrlen -= offsetof(struct sockaddr_un, sun_path);
-return PyString_FromStringAndSize(a->sun_path,
-  addrlen);
+if (splen > 0 && a->sun_path[0] == 0) {
+/* Linux abstract namespace */
+len = splen;
 }
 else
 #endif /* linux */
 {
-/* regular NULL-terminated string */
-return PyString_FromString(a->sun_path);
+/* String, up to null terminator if present */
+for (len = 0; len < splen && a->sun_path[len] != 0; len++)
+;
 }
+return PyString_FromStringAndSize(a->sun_path, len);
 }
 #endif /* AF_UNIX */
 
When parsing sockaddr_un structures returned by accept(), etc.,
only examine bytes up to supplied addrlen and do not require null
termination.

diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c
--- a/Modules/socketmodule.c
+++ b/Modules/socketmodule.c
@@ -962,18 +962,22 @@ makesockaddr(SOCKET_T sockfd, struct soc
 #if defined(AF_UNIX)
 case AF_UNIX:
 {
+

[issue7566] Add ntpath.sameopenfile support for Windows

[Brian Curtin]

Brian Curtin  added the comment:

Added in r84561.

--
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9410] Add Unladen Swallow's optimizations to Python 3's pickle.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

The patch doesn't apply cleanly anymore. Furthermore, I discovered some 
additional issues:
- load, dump, loads and dumps from the _pickle module were never used because 
they were shadowed by the same functions in pickle.py
- once the C functions above are enabled, they produce some bugs

I'm working on an updated patch, fixing the aforementioned bugs and adding a 
buffer size limit.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9763] Crashes upon run after syntax error encountered in OSX 10.5.8

[Ned Deily]

Ned Deily  added the comment:

IDLE from the Python 3.2s2 OS X installer exhibits the same buggy behavior on 
10.5 as 3.1.2 (hangs with system Tk 8.4, OK with ActiveState Tk 8.4).  There 
also seem to be some unexpected differences in IDLE behavior between 2.7 and 
3.x as if some changes were not backported.  Will triage further.

--
versions: +Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9763] Crashes upon run after syntax error encountered in OSX 10.5.8

[Ned Deily]

Ned Deily  added the comment:

IDLE from the Python 3.2a2 OS X installer exhibits the same buggy behavior on 
10.5 as 3.1.2 (hangs with system Tk 8.4, OK with ActiveState Tk 8.4).  There 
also seem to be some unexpected differences in IDLE behavior between 2.7 and 
3.x as if some changes were not backported.  Will triage further.

--
assignee:  -> ned.deily

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9763] Crashes upon run after syntax error encountered in OSX 10.5.8

[Ned Deily]

Changes by Ned Deily :


--
Removed message: http://bugs.python.org/msg115719

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9785] _PyUnicode_New(), throw and memory problem

[Trigve Siver]

Trigve Siver  added the comment:

Nevermind, I found out it was problem with ref count while using 
PyTuple_SetItem()

--
resolution:  -> invalid
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9768] IDLE / Black frame in active window

[Ned Deily]

Ned Deily  added the comment:

Closing as "works for me".  If you have a suggestion for a change to IDLE 
behavior, suggest discussing on the IDLE development list or opening a new 
issue and supply a patch.

--
resolution:  -> works for me
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9410] Add Unladen Swallow's optimizations to Python 3's pickle.

[Alexandre Vassalotti]

Alexandre Vassalotti  added the comment:

Antoine, I fixed these issues in the latest patch posted on Rietveld. Also, 
Skip added the buffer limit in Unladen Swallow (see msg112956). We just need to 
merge that.

--
Added file: http://bugs.python.org/file18777/issue1694050_19001.diff.txt

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9410] Add Unladen Swallow's optimizations to Python 3's pickle.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Here is a patch. Benchmark numbers:

* dumps():

./python -m timeit -s "import pickle, io; d={(x, 'a'): x  for x in 
range(1)}" "pickle.dumps(d)"

-> before: 100 loops, best of 3: 7.47 msec per loop
-> after: 100 loops, best of 3: 2.45 msec per loop

* loads():

./python -m timeit -s "import pickle, io; d={(x, 'a'): x  for x in 
range(1)}; d=pickle.dumps(d)" "pickle.loads(d)"

-> before: 100 loops, best of 3: 12.1 msec per loop
-> after: 100 loops, best of 3: 2.62 msec per loop

* dump():

./python -m timeit -s "import pickle, io; d={(x, 'a'): x  for x in 
range(1)}" "pickle.dump(d, io.BytesIO())"
-> before: 100 loops, best of 3: 13.2 msec per loop
-> after: 100 loops, best of 3: 2.54 msec per loop

* load():

./python -m timeit -s "import pickle, io; d={(x, 'a'): x  for x in 
range(1)}; d=pickle.dumps(d)" "pickle.load(io.BytesIO(d))"
-> before: 100 loops, best of 3: 12.7 msec per loop
-> after: 100 loops, best of 3: 11.6 msec per loop


As you can see, load() doesn't really benefit from the buffering improvements. 
The three methods see quite massive speedups.

--
Added file: http://bugs.python.org/file18778/pickle_optimizations4.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9410] Add Unladen Swallow's optimizations to Python 3's pickle.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Gosh. My patch is based on an outdated patch :(

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9410] Add Unladen Swallow's optimizations to Python 3's pickle.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Ok, this patch merges my changes with Alexandre's previous patch. Performance 
is similar as the previous posted patch.

--
Added file: http://bugs.python.org/file18779/pickle_optimizations5.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7418] hashlib : the names of the different hash algorithms

[Éric Araujo]

Éric Araujo  added the comment:

Great, thank you!

--
resolution: accepted -> fixed
stage: needs patch -> committed/rejected

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5506] io.BytesIO doesn't support the buffer protocol

[Antoine Pitrou]

Antoine Pitrou  added the comment:

This was committed in r84562.

--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue941346] AIX shared library fix

[Sébastien Sablé]

Sébastien Sablé  added the comment:

Yes Antoine, gcc only handles compilation; the linker is explicitly called 
through the ld_so_aix script which handles calling the native ld with the right 
flags to import symbols.

I will check with gcc and attach the log on Wednesday (not at work tomorrow) 
but there should be no problem.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9754] assertWarns and assertWarnsRegexp

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Committed in r84563!

--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue941346] AIX shared library fix

[Sébastien Sablé]

Sébastien Sablé  added the comment:

Hum, forget my previous note;I checked ld_so_aix and it actually calls $CC to 
handle linking not ld. I suppose gcc will call the native ld.

Anyway, I will run the test with gcc on Wednesday and know for sure if that 
works.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4026] fcntl extension fails to build on AIX 6.1

[Sébastien Sablé]

Sébastien Sablé  added the comment:

[rant: grrr, AIX is really a crappy platform; no consistency between releases; 
there are dozens of obvious bugs like that... anyway...]

The fact that there is no 64 bits objects in libbsd.a on AIX 6.1 is a 
documented bug:
http://www-01.ibm.com/support/docview.wss?uid=isg1IZ45155

They recommend to install patch APAR IZ45155.

I suppose there is nothing more we can do if the function is not available on 
the system. Maybe we could display a warning or error message and suggest to 
upgrade to a more recent patchlevel if we are on AIX and flock cannot be found?

Though if the installation is relatively up to date, there should be no problem.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4026] fcntl extension fails to build on AIX 6.1

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Well, I suppose if flock needs libbsd on AIX (which is quite weird in itself), 
and AIX fails to ship libbsd for some executable formats, then it's AIX's 
problem.

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue941346] AIX shared library fix

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Anyway, I will run the test with gcc on Wednesday and know for sure if
> that works.

Thank you! If it works, it's good for commit.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6484] No unit test for mailcap module

[R. David Murray]

R. David Murray  added the comment:

Thanks for contributing this; sorry it took so long to get a review.  Overall 
the tests look good (I didn't work through the logic of each test that looks up 
data; I'm trusting you on that part :)

Here are some comments:

1) In test_listmailcapfiles, you can use test.support.EnvironmentVarGuard and 
inside the test set the value of MAILCAPS.  That way you can test both cases 
(set and not set).

2) I notice that the listmailcapfiles docstring is inaccurate (it actually 
lists the *possible* locations of mailcap files, and applies only to unix).  
You could file a doc bug for that, but it is not an API method so it isn't a 
huge deal.

3) In test_lookup I think it might be better to hardcode the expected value 
rather than computing it.  It would make it clearer what the test was 
expecting, and remove any chance that you are just repeating the algorithm that 
the code itself is using to compute the value.

4) Your use of EnvironmentVarGuard in GetcapsTest is not technically correct, 
though it does happen to work.  You should really be doing self.env = 
test.support.EnvironmentVarGuard().__enter__() to mimic the 'with' protocol.  
It is a detail of the implementation that __enter__ returns self.

5) Why conditionalize your test on the existence of a system mailcap file?  You 
want a controlled environment for testing, so it is better, IMO, to just use 
your test mailcap file.  This will simplify your tests.
Or you could add a second test method that also does the simple checks if and 
only if one of the possible system mailcap files does exist, if your goal is to 
test that part of the code path.  (In that case you should skip the test with 
an appropriate message if no system mailcap files are found).

6) I don't see any reason why the test file needs to be named ".mailcap", you 
can specify its filename in any test where you need it.  It would indeed be 
better not to have a test file with a leading '.'.  Current convention would be 
to create a directory named 'mailcaptestdata' and put your test data files in 
there, but since you have only one it would in fact be OK to just put it 
directly in the test directory if you can come up with a clear name for it.  
Alternatively you could group those tests that need it into a single test case 
and use the new setUpClass to create it from an embedded string and 
tearDownClass to delete it afterward.

Thanks again for working on this.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9721] urlparse.urljoin() cuts off last base character with semicolon at url start

[Senthil Kumaran]

Senthil Kumaran  added the comment:

Simply applying the patch would break the testsuite of urlparse ( test_RFC3986 
case of urljoin for ';' starting joinurls). The expected behavior should be 
trim off all receding chars until a '/'  and then join the semi-colon starting 
url. 2.5 behavior is the correct one.

--
assignee:  -> orsenthil
priority: normal -> high
resolution:  -> accepted
stage:  -> needs patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1479626] Uninstall does not clean registry

[Brian Curtin]

Brian Curtin  added the comment:

#3778 covers the same issue and has more discussion. Closing this as a 
duplicate.

--
resolution:  -> duplicate
stage: unit test needed -> committed/rejected
status: open -> closed
superseder:  -> python uninstaller leave registry entries

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3778] python uninstaller leave registry entries

[Brian Curtin]

Changes by Brian Curtin :


--
nosy: +tebeka
versions:  -Python 2.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1731717] race condition in subprocess module

[Guido van Rossum]

Changes by Guido van Rossum :


--
nosy:  -gvanrossum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9025] Non-uniformity in randrange for large arguments.

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Put in a fix with r84576.  May come back to it to see if it can or should be 
optimized with C.  For now, this gets the job done.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9379] random.randrange behaviour problems

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Added a doc fix to r84576.
Advice is "don't do that" ;-)

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7889] random produces different output on different architectures

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Fixed in r84574 and r84576.  The seed function no longer uses hash() for str, 
bytes, or bytearray arguments.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9720] zipfile writes incorrect local file header for large files in zip64

[Alan McIntyre]

Alan McIntyre  added the comment:

Here's an updated patch for the py3k trunk with tests.  This pretty much 
doubles the runtime of test_zipfile64.py.  The patch also removes some 
unnecessary code from the existing test_zipfile64 tests.

Note: It looks like writestr will also suffer from a struct.pack overflow if 
it's given a ZipInfo with the third general purpose flag bit set.  I won't have 
time to address that until next weekend, probably.

--
Added file: http://bugs.python.org/file18780/zipfile-huge-files.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9786] Native TLS support for pthreads

[Kristján Valur Jónsson]

New submission from Kristján Valur Jónsson :

The following patch adds native TLS implementation for pthreads, avoiding the 
relatively slow and clunky default tls implemented in thread.c

--
components: Interpreter Core
files: pthread_tls.patch
keywords: needs review, patch, patch
messages: 115742
nosy: krisvale
priority: normal
severity: normal
status: open
title: Native TLS support for pthreads
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file18781/pthread_tls.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9787] Release the TLS lock during allocations

[Kristján Valur Jónsson]

New submission from Kristján Valur Jónsson :

Holding the "keymutex" lock during malloc and free operations is not a good 
idea.  The reason is, that custom implementations of malloc and free, can use 
the TLS themselves.  This is, for example, true in embedded situations, where 
one wants to replace malloc with, e.g. appMalloc, (to monitor the memory useage 
of Python) and appMalloc itself uses python TLS to find the current python 
State.

This change makes the malloc and free calls outside the lock.  The change in 
PyThread_set_key_value, requiring an extra lock allocate, has no significant 
performance impact since this is a rare api.

--
components: Interpreter Core
files: tlspatch.patch
keywords: patch, patch
messages: 115743
nosy: krisvale
priority: normal
severity: normal
status: open
title: Release the TLS lock during allocations
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file18782/tlspatch.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4026] fcntl extension fails to build on AIX 6.1

[Michael Haubenwallner]

Michael Haubenwallner  added the comment:

While I do agree this being an AIX bug, it is not a blocker here:
fcntl extension does not _depend_ on flock, it just does _prefer_ flock:
If not available, fcntl extension uses something else (fcntl IIRC), as it did 
(even without linking libbsd) before the AIX5.3-patch, which just added flock 
to the headers (the implementation in libbsd already has been there before the 
patch).
The problem after that AIX5.3-patch was that the compile-check found flock, and 
then fcntl extension failed to link due to missing libbsd.
So it's just for how to detect flock, where the most safe variant is both the 
compile- and link-check. When one of them fails, flock should not be flagged as 
available and the alternative gets used.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com