Re: [Python-Dev] remaining issues from Klocwork static analysis

2006-07-25 Thread Martin v. Löwis 
Neal Norwitz wrote:
> # 74 Object/funcobject.c:143Suspicious deref of ptr before NULL check

Not quite sure what it is complaining about, but

else if (PyTuple_Check(closure)) {
Py_XINCREF(closure);
}

looks indeed suspicious: Why do we check for NULL (XINCREF) when
we know closure can't be NULL (Tuple_Check). Drop the X, and see
if the warning goes away

> #169 Modules/threadmodule.c:497 Memory Leak

Does it say what memory is leaking? Perhaps it complains about
boot not being released if ident is not -1, however, in that case,
t_bootstrap will release the memory.

> # 28 Modules/_sre.c:987   Array Index Out of Bounds
> 
> Buffer overflow, array index of 'mark' may be outside the
> bounds. Array 'mark' of size 200 declared at sre.h:77 may use
> index values 0..536870911. Also there are 3 similar errors on
> lines 1006, 1225, 1237.  (Try limiting mark on line 589?)

ISTM that SRE has a limit of 100 MARK opcodes, meaning a maximum
of 100 groups per expression (so you need 200 mark pointers).
This can't overrun as sre_compile refuses to compile expressions
with more groups.

Of course, a malicious application could craft the opcodes itself
(bypassing sre_compile), in which case you could get a buffer
overrun.

The right solution is to have a dynamic marks array.

> #174 Modules/unicodedata.c:432   Array Index Out of Bounds
> 
> Buffer overflow, array index of 'decomp_prefix' may be outside the
> bounds. Array 'decomp_prefix' of size 18 declared at
> unicodedata_db.h:529 may use index values 18..255. Also there is one
> similar error on line 433.

This limit is enforced by Tools/unicode/makeunicodedata.py. There are
only 18 decomposition prefixes at the moment, yet we use 8 bits for
the decomposition prefix (makeunicodedata checks that prefix < 256)

Looking at the code, I now wonder why decomp_data can't be
"unsigned short", instead of "unsigned int" (the upper byte is the
decomposition length, and it can't be larger than 256, either).

> # 36 Modules/cPickle.c:3404   Memory Leak
> 
> Memory leak. Dynamic memory stored in 's' allocated through
> function 'pystrndup' at line 3384 is lost at line 3404.
> 
> s should not be freed on line 3407, but earlier.
> PDATA_PUSH can return on error and s will not be freed.

Correct. We should not use macros with embedded return statements.

> # 61 Modules/_sqlite/cursor.c:599  Null pointer may be dereferenced
> 
> Null pointer 'self->statement' that comes from line 674 may be
> dereferenced by passing argument 1 to function
> 'statement_mark_dirty' at line 599.

Looks like a problem. Maybe a break is missing after line 674?

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Strategy for converting the decimal module to C

2006-07-25 Thread Nick Maclaren 
Greg Ewing <[EMAIL PROTECTED]> wrote:
> 
> But we weren't talking about asynchronous exceptions,
> we were talking about floating point exceptions. Unless
> your TLB miss handler uses floating point arithmethic,
> there's no way it can get interrupted by one. (And if
> it does use floating point arithmetic in a way that
> can cause an exception, you'd better write it to deal
> with that!)

I am really not getting my message across, am I?

Yes, that is true - as far as it goes.  The trouble is that designing
systems based on assuming that IS true as far as it goes means that they
don't work when it goes further.  And it does.  Here are a FEW of the
many examples of where the simplistic model is likely to fail in an
x86 context:

The compiled code has made a data structure temporarily inconsistent
because the operation is safe (say, list insertion), and then gets an
asynchronous interrupt (e.g. SIGINT).  The SIGINT handler does some
operation (e.g. I/O) that implicitly uses floating-point, which then
interrupts.

The x86 architecture is extended to include out-of-order floating-point
as it had in the past, many systems have today, and is very likely to
happen in the future.  It is one of the standard ways to get better
performance, after all, and is on the increase.

The x86 architecture is extended to support micro-threading.  I have
not been told by Intel or AMD that either have such plans, but I have
very good reason to believe that both have such projects.  IBM and Sun
certainly do, though I don't know if IBM's is/are relevant.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  [EMAIL PROTECTED]
Tel.:  +44 1223 334761Fax:  +44 1223 334679
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] remaining issues from Klocwork static analysis

2006-07-25 Thread Georg Brandl 
Martin v. Löwis wrote:
> Neal Norwitz wrote:
>> # 74 Object/funcobject.c:143Suspicious deref of ptr before NULL check
> 
> Not quite sure what it is complaining about, but
> 
> else if (PyTuple_Check(closure)) {
> Py_XINCREF(closure);
> }
> 
> looks indeed suspicious: Why do we check for NULL (XINCREF) when
> we know closure can't be NULL (Tuple_Check). Drop the X, and see
> if the warning goes away

In comparison, the PyFunction_SetDefaults function does check for
NULL, and raises an error in this case. However, since it is a C API function
only, passing NULL is an error anyway.

Georg

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] More tracker demos online

2006-07-25 Thread Martin v. Löwis 
Currently, we have two running tracker demos online:

Roundup:
http://efod.se/python-tracker/

Jira:
http://jira.python.atlassian.com/secure/Dashboard.jspa

These installation are in various forms of demo mode and
"pre-release" (meaning that the configuration is still not
complete). They both use the sample data that Fredrik Lundh
produced at some point, so don't be surprised that they
are behind SF wrt. content.

While these might not be in the final form of operation,
I think users should already try to use them, to find
out which one they like best.

Discussions/Comments can be sent to [EMAIL PROTECTED],
however, for reports/reviews, please use the Wiki at

http://wiki.python.org/moin/CallForTrackers

You'll notice that it also lists Trac and Malone, however,
it seems that there is no progress on importing SF data
into these.

Regards,
Martin


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] More tracker demos online

2006-07-25 Thread Christian Robottom Reis 
On Tue, Jul 25, 2006 at 09:44:12PM +0200, "Martin v. Löwis" wrote:
> You'll notice that it also lists Trac and Malone, however,
> it seems that there is no progress on importing SF data
> into these.

Actually, James Henstridge has been working on an import into Launchpad
(Malone is the codename for the bugtracker component of it) over last
week. We have a demo site up at:

https://demo.launchpad.net/products/python/+bugs

Note that we're still ironing out some of the kinks with the import and
the code running there, so there will be changes before the official
announcement.
-- 
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3376 0125
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Community buildbots -- reprise

2006-07-25 Thread Grig Gheorghiu 
Hi,

This message is in response to Glyph's plea
().

Here's what Glyph said:

"I would like to propose, although I certainly don't have time to
implement, a program by which Python-using projects could contribute
buildslaves which would run their projects' tests with the latest
Python trunk.  This would provide two useful incentives: Python code
would gain a reputation as generally well-tested (since there is a
direct incentive to write tests for your project: get notified when
core python changes might break it), and the core developers would have
instant feedback when a "small" change breaks more code than it was
expected to."


I'm volunteering to organize this effort, is there is enough interest
on this list. In fact, I've done some prep work already:

 * got a domain name: pybots.org
 * got a $47/month Ubuntu-based VPS from JohnCompanies.com (root access
and everything); it's available at master.pybots.org, and it's ready to
be configured as a buildmaster for the pybots
 * got a mailing list: [EMAIL PROTECTED]

I can start configuring the Ubuntu machine as a buildmaster, and I can
also add a buildslave on the same machine that will check out the
latest Python trunk code, build it, then run the automated tests for a
sample project -- let's say for Twisted, since Glyph was the one
requesting this. This will also serve as a sample buildslave for other
people who will be interested in running buildslaves for their own
projects.

Apart from the goals stated by Glyph, I see this as a very valuable
effort in convincing people of the value of automated tests,
Python-related or not. A secondary effect I'd like to see would be for
these suites of tests to be invoked in a standard fashion -- maybe
'python setup.py test'.

If PSF can contribute some $$$ towards the hosting of the master
server, that would be appreciated, but not required. All that's
required is enough interest from the community.

Please let me know if you're interested.

Grig


http://agiletesting.blogspot.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Document performance requirements?

2006-07-25 Thread Neal Becker 
On Friday 21 July 2006 7:49 am, Nick Coghlan wrote:
> Neal Becker wrote:
> > For a recent project I needed to select a container.  There are plenty of
> > python data structures to choose from.  It seems that information on
> > performance is missing (or not easy to find).
> >
> > I think Python should include performance in the documentation of common
> > data structures to help users select the appropriate types.  Something in
> > the style of c++ STL.
>
> Do you mean absolute performance, or do you mean algorithmic order
> guarantees? I thought the latter were already documented. . .
>

The latter.  Where are they documented?
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setup.py and cross-compiling

2006-07-25 Thread Ed Swierk 
On 7/24/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> The main problem is that it is the host python that runs setup.py,
> not the target python. Various parts of distutils assume that the
> information the interpreter provides is correct, yet it is not
> in a cross-compilation case.

Well, it seems buildroot solves this main problem by building another
version of python and pygen that run on the build machine, and hacks
the Makefile to run setup.py with these instead of whatever happens to
be sitting in /usr/bin.

Thus the modules that do get built seem to work just fine, but
setup.py itself ignores all this careful hackery when determining what
modules to build and configuring distutils to search for system
libraries in various dynamically-discovered paths.

--Ed
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] More tracker demos online

2006-07-25 Thread Neil Hodgson 
Martin v. Löwis:

> Currently, we have two running tracker demos online:

   After playing with them for 30 minutes, Jira seems to have too busy
an interface and finicky behaviour: not liking the back button
sometimes (similar to SF) and clicking on diffs wants to download them
rather than view them. Its disappointing that Jira and Launchpad use
different bug IDs as continuity should be maintained with the SF bug
IDs which will be referred to in other areas such as commit messages.
They do include the SF bug ID (as a field in Jira and a nickname in
Launchpad) but this makes it harder to navigate between related bugs.
I mostly looked at "os.startfile() still doesn't work with Unicode
filenames" and I would have tagged the patch on SF with a "looks OK to
me" if SF was working.

   The text in Launchpad was a bit sparsely formatted for me so would
like to see if indvidual users can choose a different style. The
others are OK although Roundup is clearer.

   Neil
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] More tracker demos online

2006-07-25 Thread Brett Cannon 
On 7/25/06, Neil Hodgson <[EMAIL PROTECTED]> wrote:
Martin v. Löwis:> Currently, we have two running tracker demos online:   After playing with them for 30 minutes, Jira seems to have too busyan interface and finicky behaviour: not liking the back button
sometimes (similar to SF) and clicking on diffs wants to download themrather than view them. Its disappointing that Jira and Launchpad usedifferent bug IDs as continuity should be maintained with the SF bug
IDs which will be referred to in other areas such as commit messages.Stuff like continuity in bug numbers and such can be fixed in the official tracker upon launch.  More important is interface and general usage.
And as Martin said, if you wish to discuss, please do so on the infrastructue mailing list.-Brett
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] More tracker demos online

2006-07-25 Thread Terry Reedy 

""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Currently, we have two running tracker demos online:
>
> Roundup:
> http://efod.se/python-tracker/
>
> Jira:
> http://jira.python.atlassian.com/secure/Dashboard.jspa

What user name and passwords will they accept, if any?

tjr



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots -- reprise

2006-07-25 Thread Neal Norwitz 
If you want I can send you the build master cfg I setup on python.org
and some simple instructions for how to connect to it.  I don't have
time to focus on this at the moment and probably won't until 2.5 is
out.

n
--

On 7/20/06, Grig Gheorghiu <[EMAIL PROTECTED]> wrote:
> Hi,
>
> This message is in response to Glyph's plea
> ().
>
> Here's what Glyph said:
>
> "I would like to propose, although I certainly don't have time to
> implement, a program by which Python-using projects could contribute
> buildslaves which would run their projects' tests with the latest
> Python trunk.  This would provide two useful incentives: Python code
> would gain a reputation as generally well-tested (since there is a
> direct incentive to write tests for your project: get notified when
> core python changes might break it), and the core developers would have
> instant feedback when a "small" change breaks more code than it was
> expected to."
>
>
> I'm volunteering to organize this effort, is there is enough interest
> on this list. In fact, I've done some prep work already:
>
>  * got a domain name: pybots.org
>  * got a $47/month Ubuntu-based VPS from JohnCompanies.com (root access
> and everything); it's available at master.pybots.org, and it's ready to
> be configured as a buildmaster for the pybots
>  * got a mailing list: [EMAIL PROTECTED]
>
> I can start configuring the Ubuntu machine as a buildmaster, and I can
> also add a buildslave on the same machine that will check out the
> latest Python trunk code, build it, then run the automated tests for a
> sample project -- let's say for Twisted, since Glyph was the one
> requesting this. This will also serve as a sample buildslave for other
> people who will be interested in running buildslaves for their own
> projects.
>
> Apart from the goals stated by Glyph, I see this as a very valuable
> effort in convincing people of the value of automated tests,
> Python-related or not. A secondary effect I'd like to see would be for
> these suites of tests to be invoked in a standard fashion -- maybe
> 'python setup.py test'.
>
> If PSF can contribute some $$$ towards the hosting of the master
> server, that would be appreciated, but not required. All that's
> required is enough interest from the community.
>
> Please let me know if you're interested.
>
> Grig
>
> 
> http://agiletesting.blogspot.com
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/nnorwitz%40gmail.com
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] remaining issues from Klocwork static analysis

2006-07-25 Thread Neal Norwitz 
On 7/25/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Neal Norwitz wrote:
> > # 74 Object/funcobject.c:143Suspicious deref of ptr before NULL check
>
> Not quite sure what it is complaining about, but
>
> else if (PyTuple_Check(closure)) {
> Py_XINCREF(closure);
> }
>
> looks indeed suspicious: Why do we check for NULL (XINCREF) when
> we know closure can't be NULL (Tuple_Check). Drop the X, and see
> if the warning goes away

Yes, I definitely think dropping the X would make the warning go away.
 Do we want to check for a NULL pointer and raise an exception?  The
docs don't address the issue, so I think if we added a check, ie:  if
(closure && PyTuple_Check(closure)) and got rid of the X that would be
fine as well.

> > #169 Modules/threadmodule.c:497 Memory Leak
>
> Does it say what memory is leaking? Perhaps it complains about
> boot not being released if ident is not -1, however, in that case,
> t_bootstrap will release the memory.

I believe you are right, I never traced through t_bootstrap.   I think
this is a false positive.  There is some memory being leaked on thread
creation as reported by valgrind IIRC.  This doesn't seem to be it
though.

> > #174 Modules/unicodedata.c:432   Array Index Out of Bounds
> >
> > Buffer overflow, array index of 'decomp_prefix' may be outside the
> > bounds. Array 'decomp_prefix' of size 18 declared at
> > unicodedata_db.h:529 may use index values 18..255. Also there is one
> > similar error on line 433.
>
> This limit is enforced by Tools/unicode/makeunicodedata.py. There are
> only 18 decomposition prefixes at the moment, yet we use 8 bits for
> the decomposition prefix (makeunicodedata checks that prefix < 256)

Just to make sure I understand.  The code in question is accessing
decomp_prefix like this:
decomp_prefix[decomp_data[index] & 255]

So decomp_prefix will be accessed with the result of:
decomp_data[index] & 255

The first line of data is (fro unicodedata_db.h) is:

static unsigned int decomp_data[] = {
0, 257, 32, 514, 32, 776, 259, 97, 514, 32, 772, 259, 50, 259, 51, 514,

If index == 2 (or 3-5, 7-10, etc), we have:
decomp_prefix[decomp_data[2] & 255]
decomp_prefix[32 & 255]
decomp_prefix[32]

which is larger than the max size of decomp_prefix (18).  But from
what I think you stated above, index can't equal those values and the
code that prevents it is calculated a few lines above:

index = decomp_index1[(code>>DECOMP_SHIFT)];
index = decomp_index2[(index

Re: [Python-Dev] remaining issues from Klocwork static analysis

2006-07-25 Thread Neal Norwitz 
On 7/25/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
> > Neal Norwitz wrote:
> >> # 74 Object/funcobject.c:143Suspicious deref of ptr before NULL check
> >
> > Not quite sure what it is complaining about, but
> >
> > else if (PyTuple_Check(closure)) {
> > Py_XINCREF(closure);
> > }
> >
> > looks indeed suspicious: Why do we check for NULL (XINCREF) when
> > we know closure can't be NULL (Tuple_Check). Drop the X, and see
> > if the warning goes away
>
> In comparison, the PyFunction_SetDefaults function does check for
> NULL, and raises an error in this case. However, since it is a C API function
> only, passing NULL is an error anyway.

Heh, that was me that added it 10 days ago. :-)
Might as well do the same here.

n
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots -- reprise

2006-07-25 Thread Grig Gheorghiu 
On 7/25/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
If you want I can send you the build master cfg I setup on python.organd some simple instructions for how to connect to it.  I don't havetime to focus on this at the moment and probably won't until 
2.5 isout.n--Sure. I'm still a bit unclear on whether you want me to coordinate this
by adding buildslaves to the build master cfg, adding build steps etc.
I'll gladly do it if you need help. I'll need access to the server and
proper permissions of course.

Grig 
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] remaining issues from Klocwork static analysis

2006-07-25 Thread Martin v. Löwis 
Neal Norwitz wrote:
>> Not quite sure what it is complaining about, but
>>
>> else if (PyTuple_Check(closure)) {
>> Py_XINCREF(closure);
>> }
>>
>> looks indeed suspicious: Why do we check for NULL (XINCREF) when
>> we know closure can't be NULL (Tuple_Check). Drop the X, and see
>> if the warning goes away
> 
> Yes, I definitely think dropping the X would make the warning go away.
> Do we want to check for a NULL pointer and raise an exception?  The
> docs don't address the issue, so I think if we added a check, ie:  if
> (closure && PyTuple_Check(closure)) and got rid of the X that would be
> fine as well.

The docs do address the issue:

\var{closure} must be \var{Py_None} or a tuple of cell objects.

It doesn't allow for NULL, and None indicates that the closure
should become NULL. The only caller of it in the core will never
pass NULL.

If you want to check that this is not NULL on the grounds that
somebody may call it incorrectly, then you should also check that
op is not NULL, because somebody may call it incorrectly.

> The first line of data is (fro unicodedata_db.h) is:
> 
> static unsigned int decomp_data[] = {
>0, 257, 32, 514, 32, 776, 259, 97, 514, 32, 772, 259, 50, 259, 51, 514,

Read this as
0: sentinel
257 = 256 | 1: length 1, prefix 1
32: U+0020
514 = 512 | 2: length 2, prefix 2
32: U+0020
776: U+308
...

> Is that correct?  If so, would it be correct to add:
> 
>unsigned short prefix_index = decomp_data[index] & 255;
>assert(prefix_index < (sizeof(decomp_prefix)/sizeof(*decomp_prefix)));

Yes, that would be correct.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] More tracker demos online

2006-07-25 Thread Martin v. Löwis 
Neil Hodgson wrote:
> Its disappointing that Jira and Launchpad use
> different bug IDs as continuity should be maintained with the SF bug
> IDs which will be referred to in other areas such as commit messages.

My plan is to keep the SF redirector alive, so python.org/sf/
should continue to direct you to the right item in the new tracker.
This can only be done when we actually make the switch, since currently
the redirector still needs to direct to SF.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] remaining issues from Klocwork static analysis

2006-07-25 Thread Neal Norwitz 
On 7/25/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> >
> > Yes, I definitely think dropping the X would make the warning go away.
> > Do we want to check for a NULL pointer and raise an exception?  The
> > docs don't address the issue, so I think if we added a check, ie:  if
> > (closure && PyTuple_Check(closure)) and got rid of the X that would be
> > fine as well.
>
> The docs do address the issue:
>
> \var{closure} must be \var{Py_None} or a tuple of cell objects.
>
> It doesn't allow for NULL, and None indicates that the closure
> should become NULL. The only caller of it in the core will never
> pass NULL.
>
> If you want to check that this is not NULL on the grounds that
> somebody may call it incorrectly, then you should also check that
> op is not NULL, because somebody may call it incorrectly.

We never really did address this issue did?  A while back we talked
about whether to assert vs check and do PyErr_BadInternalCall().  I
don't remember a clear resolution (though my memory).  I vaguely
remember a preference towards asserting, but I don't know if that was
in all cases or maybe it was just my preference. :-)

I'm happy to assert here too.  But it's really a broader question.  I
guess I'm even happy to just remove the X.  It would be nice to handle
this consistently going forward.

n
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] More tracker demos online

2006-07-25 Thread Martin v. Löwis 
Terry Reedy wrote:
> ""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message 
> news:[EMAIL PROTECTED]
>> Currently, we have two running tracker demos online:
>>
>> Roundup:
>> http://efod.se/python-tracker/
>>
>> Jira:
>> http://jira.python.atlassian.com/secure/Dashboard.jspa
> 
> What user name and passwords will they accept, if any?

The roundup installation accepts SF user names, no
password; you can then set the password if you want to.

The Jira installation accepts SF user names; you have make
it send you a password reminder. The registered email
address is the SF one.

If you have problems getting in, please let me know.
I (and the other infrastruture people) have admin privs
on these installations, so I can learn how to administrate
them if something goes wrong :-)

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] remaining issues from Klocwork static analysis

2006-07-25 Thread Martin v. Löwis 
Neal Norwitz wrote:
> We never really did address this issue did?  A while back we talked
> about whether to assert vs check and do PyErr_BadInternalCall().  I
> don't remember a clear resolution (though my memory).  I vaguely
> remember a preference towards asserting, but I don't know if that was
> in all cases or maybe it was just my preference. :-)
> 
> I'm happy to assert here too.  But it's really a broader question.  I
> guess I'm even happy to just remove the X.  It would be nice to handle
> this consistently going forward.

I would just remove the X.

If we want to handle it consistently, we would have to check all pointer
parameters in all functions; this would be a huge task (and for little
value, IMO).

In any case, "closure && PyTuple_Check(closure)" would be wrong, since
it then goes into

PyErr_Format(PyExc_SystemError,
 "expected tuple for closure, got '%.100s'",
 closure->ob_type->tp_name);

which crashes just the same.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] remaining issues from Klocwork static analysis

2006-07-25 Thread Neal Norwitz 
On 7/25/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Neal Norwitz wrote:
> > We never really did address this issue did?  A while back we talked
> > about whether to assert vs check and do PyErr_BadInternalCall().  I
> > don't remember a clear resolution (though my memory).  I vaguely
> > remember a preference towards asserting, but I don't know if that was
> > in all cases or maybe it was just my preference. :-)
> >
> > I'm happy to assert here too.  But it's really a broader question.  I
> > guess I'm even happy to just remove the X.  It would be nice to handle
> > this consistently going forward.
>
> I would just remove the X.

I'll do that here since it's the easiest.

> If we want to handle it consistently, we would have to check all pointer
> parameters in all functions; this would be a huge task (and for little
> value, IMO).

I'm not suggesting changing existing code, unless we find issues.  I
agree that it would be a huge task and of little value.  I was
thinking about for future code.  I guess we aren't writing a lot of
new C APIs in 2.x, so it really doesn't much there matter.  Though for
3k, it would be nice to make it consistent as new APIs are written or
old APIs are cleaned up.

n
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] new security doc using object-capabilities

2006-07-25 Thread Greg Ewing 
> Phillip J. Eby wrote:
> 
> > And what about code that needs to pass on a subset of a capability?

With one object == one capability, there is no such
thing as a subset of a capability -- the capabilities
are the atomic units at which you control access. So
you need to make them fine-grained enough to begin
with.

--
Greg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com