[Python-Dev] FW: static analysis of python source
I just ran some static analysis of the python core 2.5 with Visual Studio team
system.
There was the stray error discovered. I will update the most obvious ones.
Some questions, though:
This code in binascii.c, line 1168 (and again 1238) is wrong:
while (in datalen) {
if ((data[in] 126) ||
(data[in] == '=') ||
(header data[in] == '_') ||
((data[in] == '.') (linelen == 1)) ||
(!istext ((data[in] == '\r') || (data[in] == '\n'))) ||
((data[in] == '\t' || data[in] == ' ') (in + 1 == datalen))
||
((data[in] 33)
(data[in] != '\r') (data[in] != '\n')
(quotetabs ((data[in] != '\t') || (data[in] != ' ')
The final ((data[in] != '\t') || (data[in] != ' ')) is always true. What
is the right form? ((data[in] == '\t') || (data[in] == ' ')) ?
1)
2) There is a lot of code that goes like this:
f-buf = PyMem_Realloc(f-buf, newsize);
if (!f-buf)
return PyErr_NoMemory(), 0;
Now, this if Realloc fails, this causes a memory leak. Is there any interest
to fix this flawed pattern wholesale?
Cheers,
Kristjan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FW: static analysis of python source
Kristján Valur Jónsson [EMAIL PROTECTED] wrote: I just ran some static analysis of the python core 2.5 with Visual Studio team system. There was the stray error discovered. I will update the most obvious ones. [snip] 2) There is a lot of code that goes like this: f-buf = PyMem_Realloc(f-buf, newsize); if (!f-buf) return PyErr_NoMemory(), 0; Now, this if Realloc fails, this causes a memory leak. Is there any interest to fix this flawed pattern wholesale? I believe the idea is that if you run into a MemoryError, in particular on linux (whose allocator will give you a nonzero pointer well beyond what was actually available), you can't really trust the state of the interpreter, so it is expected that Python will be ending shortly. Forcing the leak (leaving the code as-is) basically encourages the interpreter to have more and more errors before the expected, possibly inevitable (and perhaps desireable) quitting of the Python interpreter. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FW: static analysis of python source
I believe the idea is that if you run into a MemoryError, in particular on linux (whose allocator will give you a nonzero pointer well beyond what was actually available), you can't really trust the state of the interpreter, so it is expected that Python will be ending shortly. Forcing the leak (leaving the code as-is) basically encourages the interpreter to have more and more errors before the expected, possibly inevitable (and perhaps desireable) quitting of the Python interpreter. I don't think that this is the intention (and if it is, I think this intention is flawed). If you really need to shut down ASAP, you should exit(), not raise an exception. Raising MemoryError will exit soon enough, anyway. So I don't think the leak is a good thing - but I don't think it is a bad thing, either, since the code is essentially dead (i.e. it is fairly unlikely that it ever triggers). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
