AD or PyBUF_WRITE.
In the Python source tree, it could completely replace PyBuffer_FillInfo()
and PyMemoryView_FromBuffer().
Stefan Krah
___
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
represent the null character."
So I think it should be either NUL or "null character" with the lower
case spelling.
Stefan Krah
___
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
d PEP-3118 grow support for int8_t and uint8_t,
I think "b" and "B" should probably be restricted to integers.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscri
Antoine Pitrou wrote:
> On Thu, 18 Aug 2011 18:57:00 +0200
> Stefan Krah wrote:
> >
> > Oh no, the name isn't quite right then. It should be a replacement
> > for the combination PyBuffer_FillInfo()/PyMemoryView_FromBuffer()
> > and it should tempora
Barry Warsaw wrote:
> My online dictionaries prefer "file system" to be two words, so for me,
> FileSystemError is preferred.
+1
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
es sense. clang has different warnings and the versions
>= 2.9 apparently optimize extremely aggressively. Probably it would
be most useful to run these bots with -O2 (and not --with-pydebug).
Stefan Krah
___
Python-Dev mailing list
Python-D
cleaner, but have_long_long is pretty
established elsewhere (for example in pyport.h).
Stefan Krah
___
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
; It's easier for my brain because I just have 2 versions of the same
> code, not 3!
I also prefer /usr/bin/merge and I've never quite figured out the GUI.
Not that I spent a lot of time on it, since the "legacy" merge works
well (and is self-explanatory).
Stefan Kr
know what input is currently regarded as a decimal
digit. See also:
http://bugs.python.org/issue10557
http://bugs.python.org/issue10557#msg123123
"The API won't go away (it does have its use and is being
used in 3rd party extensions) [...]
ascii(PyObject *self)
{
return PyUnicode_TransformDecimalAndSpaceToASCII(self);
}
#endif
Will PyUnicode_TransformDecimalAndSpaceToASCII() be public?
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/li
as well: Decimal("\u180E1.233").
> > Will PyUnicode_TransformDecimalAndSpaceToASCII() be public?
>
> It's already included in 3.2, so it can't be removed that easily.
> I wish it had been private, though - we have way too many API functions
> dealing with
foo).
>
> I prefer PyUnicode_IS_READY(foo) < 0 over PyUnicode_IS_READY(foo) == -1.
Do you mean PyUnicode_READY(foo) < 0? I also prefer that idiom.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
on.org/issue11732
Stefan Krah
___
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
r that.
Yes, the Fedora bot currently fails the bdist_rpm tests:
http://www.python.org/dev/buildbot/all/builders/AMD64%20Fedora%20without%20threads%203.x/builds/873/steps/test/logs/stdio
Stefan Krah
___
Python-Dev mailing list
Python-Dev@pyt
issue13061 and Issue11149.
For clang version 3.0 (trunk 139691) on FreeBSD this is the case.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/opti
gt; m_array = memoryview(a)
>>> m_bytes = memoryview(b)
>>> m_cast = m_array.cast('B')
>>> m_bytes == m_cast
True
>>> hash(b) == hash(a)
Traceback (most recent call last):
File "", line 1, in
TypeError: unhashable type:
> > True
> > >>> hash(b) == hash(a)
> > Traceback (most recent call last):
> > File "", line 1, in
> > TypeError: unhashable type: 'array.array'
>
> In this case, the memoryview wouldn't be hashable either.
Hmm, the point w
y necessarily have to use the same hash, since:
exporter = m1 ==> hash(exporter) = hash(m1)
m1 = m2 ==> hash(m1) = hash(m2)
Am I missing something?
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
Antoine Pitrou wrote:
> Stefan Krah wrote:
> > I think they necessarily have to use the same hash, since:
> >
> > exporter = m1 ==> hash(exporter) = hash(m1)
> > m1 = m2 ==> hash(m1) = hash(m2)
> >
> > Am I missing something?
>
> The hash
e it. The
> function is already deprecated beacuse it uses the deprecated Py_UNICODE type.
I'd be fine with removing the function in 3.4. For consistency,
it might be better to remove it in 4.0 together with all the other
deprecated functions (at least I understood that t
}
The main issue is that there is no portable function mbst_to_utf8()
that uses the current locale. If possible, it would be great to have
such a thing in the C-API.
I'm not sure why the b'\xA0' problem only occurs in Solaris. Many systems
have this thousands separator.
Stefan Krah wrote:
> I'm not sure why the b'\xA0' problem only occurs in Solaris. Many systems
> have this thousands separator.
Are LC_CTYPE and LC_NUMERIC set to the same value on the buildbot? Otherwise
you encounter http://bugs.python.org/issu
It can be a motivation to fix the root of the issue ;-)
Yes, if the cause is a broken mbstowcs() that sounds good.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://ma
sk like improving code coverage or support of
> some rare platforms?
On some buildbots compiler warnings are starting to accumulate. Installing
a recent version of gcc and fixing those might be a good task. If the
participants are new to buildbot, it might even be interesting f
disable the warning. I would prefer if stop using these kinds of
> hacks.
Do you mean (void)write(...)? Many people think this is good practice,
since it indicates to the reader that the return value is deliberately
ignored.
Stefan Krah
___
Pyt
ecimal module.
Apart from the rarity of these systems, decimal.py is arbitrary precision.
If I restricted _decimal to DECIMAL64, I could probably speed it up further.
All that said, personally I wouldn't have problems with a chunked representatio
the release managers.
Stefan Krah
___
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
Antoine Pitrou wrote:
> Stefan Krah wrote:
> > In Python 3.3 most issues with the memoryview object have been fixed
> > in a recent commit (3f9b3b6f7ff0).
>
> Oh and congrats for doing this, of course.
Thanks!
Stefan Krah
_
tly have three +1 for "too complex to backport".
I'm not strongly in favor of backporting myself. The main reason for me
would be to prevent having additional 2->3 or 3->2 porting obstacles.
Stefan Krah
___
Python-Dev mailing
ures will ever be
used. Even if a new 3.3 project is started that needs to be backwards
compatible, I can imagine that people will shun anything that 3to2 isn't
able to handle (out of the box).
This would be less of an issue if the officially sanctioned way of porting
were the
he
master branch (as it should).
5) For the user: running 2to3 on install sends the signal that version 2
is the real version. This is not the case if there are, say, src2/
and src3/ directories in the distribution.
Stefan Krah
's possible or best for other projects. I do
think though that choosing the separate branches strategy will pay off
eventually (at the very latest when Python-2.7 will reach the status
that Python-1.5 currently has).
Stefan Krah
[1] I don't
th* versions do not use their full
potential, but that is strongly related to the "using all (new) features"
item in the list.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-d
, mainly
> involved with floating point precision: test_cmath, test_math and test_float.
I think you have to compile with "-fp-model strict".
In general, please submit suspected bugs on http://bugs.python.org/
(after searching the archives) and post things like speed comparisons on
er.html#Py_buffer
http://docs.python.org/dev/c-api/typeobj.html#buffer-object-structures
Since the Py_buffer.obj filed was undocumented in 3.2, I think we're within
out rights to restrict the field to the exporter.
Stefan Krah
___
Python-Dev mai
_ and should therefore support the types in question.
Stefan Krah
___
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
tests or they don't test against a
new Python version is that really our problem?
Modules do need to be recompiled anyway due to the removal of
Py_buffer.smalltable, otherwise they will almost certainly crash.
Perhaps an addition to whatsnew/3.3 woul
n that needs to be absorbed.
> it's still not all that unlikely that it breaks user code (assuming that it
> currently works). The decision to enforce this restriction should not be
> taken lightly.
As I said, user code using the (also undocumented) Py_buffer.smalltable
will also be bro
Stefan Krah wrote:
> > Careful. There are tons of code out there that use the buffer interface,
> > and the "obj" field has been the way to handle the buffer release ever
> > since the interface actually worked (somewhere around the release of Py3.0,
> > IIRC).
the one that exports the buffer?
It doesn't have to be. This is now possible:
>>> from _testbuffer import *
>>> exporter = b'123'
>>> nd = ndarray(exporter)
>>> m = memoryview(nd)
>>> nd.obj
b'123'
>>> m.obj
Stefan Krah
Stefan Krah wrote:
> > Why would the object that bf_getbuffer() is being called on have to
> > be identical with the one that exports the buffer?
>
> It doesn't have to be. This is now possible:
>
> >>> from _testbuffer import *
> >>> expo
Alex Leach wrote:
> Can you translate Intel's suggestion into a patch for ffi64?
Well probably, but this really belongs on the bug tracker. Also, as I said,
there are many issues with higher priority.
Stefan Krah
___
Python-Dev mailing lis
ered re-exporting rather than redirecting
the standard model and built the test suite around it.
Stefan Krah
___
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
part of a getbufferproc, exporter MUST be
set to the exporting object. Otherwise, exporter MUST be NULL."
Stefan Krah
___
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
et this field to NULL. But even if
existing code uses the view.obj==NULL scheme from PyBuffer_FillInfo()
correctly, it will still work in the new implementation.
I'd just prefer to forbid this in the documentation, because it's much
easier to remember: getbuffer "returns
ow hypothetical) API
change.
I would have some comments about valid uses of explicit aborts in a library
that essentially perform the same function as compiling said library with
-D_FORTIFY_SOURCE=2 and -ftrapv (i.e. crash when an external program violates
a function contract), but I
ed view==NULL in the future or
can we remove the special case?
Stefan Krah
___
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
Nick Coghlan wrote:
> On Tue, Mar 6, 2012 at 8:34 PM, Stefan Krah wrote:
> > The obvious question is: Will anyone need view==NULL in the future or
> > can we remove the special case?
>
> The public API will still need a guard (to report an error), but +1
> for o
27; -> UCS2
'w' -> UCS4
Actually we could even add 'a' -> ASCII, then a unicode object could
be a buffer provider that gives the correct view according to the
maxchar in the buffer. This opens the possibility for strongly typ
ee struct module) the format
is unsigned bytes, which are integers in struct module syntax:
>>> unsigned_bytes = memoryview(b"abc")
>>> unsigned_bytes.format
'B'
>>> char_array = unsigned_bytes.cast('c')
>>> char_array.format
&
aised the issue is this: If Python-3.3 is shipped
with 'u' -> UCS4 in the array module and *then* someone figures out that
the above format codes are a great idea, we'd be stuck with yet another
format code incompatibility.
Stefan Krah
Antoine Pitrou wrote:
> time.monotonic(fallback=False) would be a better API.
+1
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/opti
, but vast knowledge required (how do you prove that
using (freefunc) is safe if it's the first usage in the tree?).
http://bugs.python.org/file21610/atexit-leak.patch
I think there are many issues like that one where the implications
of a short patch can only be assessed by small n
L to the issue itself?
That sounds like an excellent plan. :)
http://bugs.python.org/issue11826
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
Hello,
you might be aware of it already. In case not, it appears that svn.python.org
and the buildbots are down.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
#x27;t bother to find out how to restart it just for me. I presume
Martin knows the setup and will do it later.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://ma
rats Stefan! And thanks for the huge chunk of code.
Thanks, much appreciated. I'll take the opportunity to thank you in
return for the gigantic amount of work you've done on Python in the
past year!
Stefan Krah
___
Python-Dev mailing list
stable under qemu with 512MB
allocated for the VM. I've never limited CPU or disk space. On an i7
quad core with 8GB of memory, I've been running two buildbot VMs,
four deccheck processes at 100% CPU and a web server without any
kind of noticable performance
h-system-libmpdec option with the caveat that
changes will probably make it first into the libmpdec shipped
with Python, see also:
http://bugs.python.org/issue7652#msg155744
On the bright side, I don't expect many changes, since the specification
is stable.
Stefan Krah
___
he impression that 3.x is already
used in the financial community, where web framework dependencies aren't an
issue.
On the web side, there seems to be a huge interest in speeding up database
accesses, so let me evangelize again: Database applications using decimal
will run 12x faster in 3.
We've got to keep you on your toes, don't we? :)
> Fortunately the libmpdec directory should be reusable as is.
> Nice work!
Thanks, also for helping out with the MutableMapping context.
Stefan Krah
___
Python-Dev mailing list
Python-
erence gets larger and larger.
For huge numbers _decimal is also faster than int:
factorial(100):
_decimal, calculation time: 6.844487905502319
_decimal, tostr(): 0.033592939376831055
int, calculation time: 17.96010398864746
int, tostr(): ... still running ...
Stefa
Antoine Pitrou wrote:
> > On the web side, there seems to be a huge interest in speeding up database
> > accesses, so let me evangelize again: Database applications using decimal
> > will run 12x faster in 3.3.
>
> Are you sure it isn't 12.5x ?
Well, that was mar
the
presence of fixed elements.
Stefan Krah
___
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
7;s almost the center of my attention
(when I should be focusing on the text).
Perhaps users can discover the collapsible sidebar without the '<<' hint?
Or let it move up like in the existing version?
Stefan Krah
___
Python-Dev mailing list
and I personally don't have
> *that* strong a preference either way.
Maybe. It's hard to determine. It's just that I don't see fixed search
boxes or fixed elements like '<<' on big name websites (who may or
there is no complicated base conversion.
> If yes, would it be possible to reuse the multiply algorithm of _decimal
> (and maybe of other functions) for int? Or does it depend heavily on
> _decimal internal structures?
Large parts of the Number Theoretic Transform could be reused, but there
wo
ing initialization.
All operations in _decimal.c follow the same scheme:
/* dec contains an mpd_t with MPD_MINALLOC words. */
dec = dec_alloc();
/* Initialization by a libmpdec function. MPD() is the
accessor macro for the mpd_t. */
mpd_func(MPD(dec), x, y, ...);
/* From here on dec
ong *ns)
> {
> int result = 0;
> -PyObject *divmod;
> +PyObject *divmod = NULL;
> divmod = PyNumber_Divmod(py_long, billion);
> if (!divmod)
> goto exit;
If I'm not mistaken, divmod was already unconditional
ted of type 'a * kwargs
In Python it makes sense if (for the purpose of raising an error) one assumes
that {"times":(0, 0)}, {"ns":(0, 0)} and {"times":(0, 0), "ns":(0, 0)} have
different types.
Stefan Krah
___
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
" a tuple of two ints or None",
Unrelated to this commit, but 'time' should be 'times'.
Stefan Krah
___
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
larry.hastings wrote:
> Update Misc/NEWS for issues #14127 and #14705. (And, technically, #10148.)
>
> + * De-vararg'd PyArg_ParseTupleAndKeywords()
This looks like an accidental commit. Is there an issue number for the
varargs changes (just out of interest)?
mething else than
> curiosity of mind?
_decimal is about 12% faster without threads, because the expensive
thread local context can be disabled.
On OpenBSD threading leads to strange problems like delayed signals
in the REPL http://bugs.python.org/issue8714 . Without threads these
problems don
his reduces the speed difference to about 4%!
Stefan Krah
___
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
Antoine Pitrou wrote:
> On Wed, 9 May 2012 11:26:29 +0200
> Stefan Krah wrote:
> > Antoine Pitrou wrote:
> > > > _decimal is about 12% faster without threads, because the expensive
> > > > thread local context can be disabled.
> > >
> >
Stefan Krah wrote:
> > > Nice. This reduces the speed difference to about 4%!
> >
> > Note that you don't need the actual thread id, the Python thread state
> > is sufficient: PyThreadState_GET should be a simply variable lookup in
> > release builds.
>
pyport.h or
Python.h.
> I'd also hard-code that sys.maxsize ought to be either 2**31-1 or 2**63-1.
I would have done exactly that, but the example in the docs that was quoted
to me in the issue uses > 2**32:
http://docs.python.org/dev/library/platform.html
Stefan Krah
__
Yury Selivanov wrote:
> What's the status of Python 3.3 beta 2?
It's postponed until next weekend.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://ma
s a different
layout, the exporter must perform a full cast so that the above
mentioned invariants are kept.
The disadvantage of this is that the original layout is lost for
the consumer. I do not know if there is a use case that requires
the consumer to have the original
g flags in the new MemoryViewObject.
It would be handy to have these flags in the Py_buffer structure, but
that can only be considered for a future version of Python, perhaps no
earlier than 4.0. The same applies of course to all three points that
I made above.
Stefan Krah
___
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
rides data, can strides data be
> provided anyway, if that's easier than returning NULL but is
> consistent with doing so?
This is not explicitly disallowed, but IMO the intent is that strides
should also be NULL in that case. For example, strides==NULL might be
used for a quick C-contiguit
http://docs.python.org/dev/c-api/buffer.html#PyBUF_WRITABLE
Stefan Krah
___
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
t would also be possible to add new flags for things like byte order.
The main reason is that it turns out that in any general C function that
takes a Py_buffer argument one has to reconstruct full information anyway,
otherwise obscure cases *will* be overlooked (in the absence of a formal
proo
SPARC buildbot.
Stefan Krah
___
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
g it.
Can we continue this discussion some other time, perhaps after 3.3 is out?
I'd like to respond, but need a bit more time to think about it than I have
right now (for this issue).
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.or
ut. In case someone is
> interested in this, see
> http://www.opencsw.org/extend-it/signup/to-upstream-maintainers/
Thanks for the link. Perhaps I'll try to get an account there.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
rs the problem:
http://bugs.python.org/issue15477
Stefan Krah
___
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
al revisions
3 warnings encountered!
Stefan Krah
___
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
versions of hg:
http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/23195
So it looks like a known issue, see also:
https://bugzilla.mozilla.org/show_bug.cgi?id=644904
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
http://
;s 'n' format specifier actually relies on the CRT locale. The
functions in question are in libmpdec, so on Windows it is not possible
to compile a static libmpdec and build the module from that.
Well, it's possible, but setting the locale from Python then h
' when the memoryview is deallocated?
Permanent memoryviews can now be safely created with PyMemoryView_FromMemory().
PyMemoryView_FromBuffer() isn't really that useful any more.
It's hard to document all this in a few lines. Perhaps you can open an
issue for this?
Stefan Kra
r you?
Not yet, please do if it's no problem.
Stefan Krah
___
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
Your request for analysis of Python has been completed. The results
> should be available now in the database: http://scan5.coverity.com:8080/
Thanks Christian, works perfectly!
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
The mailing list would be nice especially if we could get the results in
verbose text form, but I don't know if that's possible.
BTW, do we keep all buffer overruns secret or can we post them on the tracker
if it's an off-by-one and unlikely to be
mit messages.
That said, for users of the Coverity web interface it's clearly useful.
Stefan Krah
___
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
x27;s avoid that in the future.
Stefan Krah
___
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
Coverity appears to have serious problems with shortcut evaluations in many
places.
NG(interfaceName)) will not overrun
ifr.ifr_name and ifr.ifr_name is always NUL terminated.
So IMO the strcpy() was safe and the report is a false positive.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
t; k = PyLong_FromVoidPtr(key);
> if (k == NULL)
> @@ -79,6 +79,7 @@
>
> return ste;
> fail:
> +Py_XDECREF(k);
> Py_XDECREF(ste);
I think 'k' is owned by the PySTEntryObject after it is assigned here:
ste->ste_id = k;
So ste_dealloc() will call Py
Christian Heimes wrote:
> Am 12.09.2012 16:22, schrieb Stefan Krah:
> > This is a false positive:
>
> You might be right. But did you notice that there is much more code
> beyond the large comment block in PyLong_FromString()? There might be
> other code paths that push
201 - 300 of 324 matches
Mail list logo
