[issue9518] PyModuleDef_HEAD_INIT does not explicitly initial all fields of m_base

2010-08-04 Thread Dave Malcolm
New submission from Dave Malcolm : Attempting to compile Python 3 extension modules on GCC with "-Wmissing-field-initializers" enabled leads to warnings from the PyModuleDef_HEAD_INIT macro Seen attempting to build SELinux python bindings against python 3.1 with "-W -W

[issue9518] PyModuleDef_HEAD_INIT does not explicitly initialize all fields of m_base

2010-08-04 Thread Dave Malcolm
Changes by Dave Malcolm : -- title: PyModuleDef_HEAD_INIT does not explicitly initial all fields of m_base -> PyModuleDef_HEAD_INIT does not explicitly initialize all fields of m_base ___ Python tracker <http://bugs.python.org/iss

[issue17206] Py_XDECREF() expands its argument multiple times

2013-02-14 Thread Dave Malcolm
New submission from Dave Malcolm: When running my refcount static analyzer [1] on a large corpus of real-world C extension code for Python, I ran into the following construct in various places: Py_XDECREF(PyObject_CallObject(callable, args)); This is bogus code: Py_XDECREF expands its

[issue17258] multiprocessing.connection challenge implicitly uses MD5

2013-02-20 Thread Dave Malcolm
New submission from Dave Malcolm: Within multiprocessing.connection, deliver_challenge() and answer_challenge() use hmac for a challenge/response. hmac implicitly defaults to using MD5. MD5 should no longer be used for security purposes. See e.g. http://www.kb.cert.org/vuls/id/836068 This

[issue16754] Incorrect shared library extension on linux

2013-03-06 Thread Dave Malcolm
Dave Malcolm added the comment: For reference, quoting PEP 3149: >>> sysconfig.get_config_var('SO') '.cpython-32mu.so' -- nosy: +dmalcolm ___ Python tracker <h

[issue17449] dev guide appears not to cover the benchmarking suite

2013-03-17 Thread Dave Malcolm
New submission from Dave Malcolm: Does the devguide document the benchmarking suite anywhere? I can't see it anywhere in the index on http://docs.python.org/devguide/ and google doesn't seem to show anything. suggested content: * how to run the benchmarks for a Python 2 impl

[issue17547] "checking whether gcc supports ParseTuple __format__... " erroneously returns yes with gcc 4.8

2013-03-25 Thread Dave Malcolm
New submission from Dave Malcolm: It appears that gcc's -Wformat warning changed from being on by default in gcc 4.7 and earlier to being off by default in gcc 4.8, needing to be enabled with -Wformat (or -Wall), if I'm reading: http://gcc.gnu.org/viewcvs/gcc?view=revision&r

[issue17772] test_gdb doesn't detect a gdb built with python3.3 (or higher)

2013-04-17 Thread Dave Malcolm
Dave Malcolm added the comment: I didn't know that gdb supported embedding Python 3. Is this a set of patches you're applying downstream, or an official gdb feature? If so, it means everyone coding to the gdb API needs to somehow make their FOO-gdb.py files be Python 3-

[issue17772] test_gdb doesn't detect a gdb built with python3.3 (or higher)

2013-04-17 Thread Dave Malcolm
Dave Malcolm added the comment: Thanks. Does upstream gdb have a plan dcoumented somewhere for how to deal with all of the FOO-gdb.py files. Are they expected to be coded to the common Python 2/3 subset? -- ___ Python tracker <h

[issue17547] "checking whether gcc supports ParseTuple __format__... " erroneously returns yes with gcc 4.8

2013-04-23 Thread Dave Malcolm
Dave Malcolm added the comment: On Sat, 2013-04-20 at 21:25 +, Ned Deily wrote: > Ned Deily added the comment: > > Dave, any reason this shouldn't go into the imminent 2.7.5 and 3.3.2 releases? I was trying to think of one; the only reason I can think of is if there are any

[issue17547] "checking whether gcc supports ParseTuple __format__... " erroneously returns yes with gcc 4.8

2013-04-23 Thread Dave Malcolm
Dave Malcolm added the comment: BTW, is that GCC format checking code available anywhere? Am I right in thinking that it was an out-of-tree patch to GCC, from the pre-plugin days? [My cpychecker code adds some similar checking, but it doesn't use this attr

[issue17547] "checking whether gcc supports ParseTuple __format__... " erroneously returns yes with gcc 4.8

2013-04-24 Thread Dave Malcolm
Dave Malcolm added the comment: On Wed, 2013-04-24 at 10:48 +, Alex Leach wrote: > Alex Leach added the comment: > > I don't think I can tell you anything you don't know already, but ... > > On Tue, 23 Apr 2013 19:38:18 +0100, Dave Malcolm > wrote: &g

[issue17833] test_gdb broken PPC64 Linux

2013-04-24 Thread Dave Malcolm
Dave Malcolm added the comment: Is this an optimized or a debug build? (aka --with-pydebug) What are the optimization flags passed to the C compiler? -- nosy: +dmalcolm ___ Python tracker <http://bugs.python.org/issue17

[issue17833] test_gdb broken PPC64 Linux

2013-04-24 Thread Dave Malcolm
Dave Malcolm added the comment: Thanks. I can't see from that output what's going wrong. Can you apply the following patch, which (I hope) will print more detailed info where the failure happens. -- keywords: +patch Added file: http://bugs.python.org/file30005

[issue17833] test_gdb broken PPC64 Linux

2013-04-24 Thread Dave Malcolm
Dave Malcolm added the comment: Looking at test_gdb.out, the issue is that the threads waiting for the GIL have e.g. this at the top of their backtrace: Thread 2 (Thread 0x3fffb14af200 (LWP 37119)): #0 0x008075181ea8 in __pthread_cond_timedwait (cond=0x103ea140 , mutex=0x103ea170

[issue17833] test_gdb broken PPC64 Linux

2013-04-24 Thread Dave Malcolm
Dave Malcolm added the comment: Can you try this candidate fix? -- Added file: http://bugs.python.org/file30007/possible-fix.patch ___ Python tracker <http://bugs.python.org/issue17

[issue17833] test_gdb broken PPC64 Linux

2013-05-06 Thread Dave Malcolm
Changes by Dave Malcolm : -- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.or

<    1   2   3   4   5