STINNER Victor victor.stin...@haypocalc.com added the comment:
My stronger argument was that %.100s was never supported. I am wrong: Python 2
is only to truncate strings in PyErr_Format() (PyString_FromFormatV() supports
precision for %s format). As I am the only one wanting to changing that,
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
resolution: - invalid
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10833
___
Roundup Robot devnull@devnull added the comment:
New changeset 74d3dc78f0db by Victor Stinner in branch 'default':
Issue #10833: Use PyUnicode_FromFormat() and PyErr_Format() instead of
http://hg.python.org/cpython/rev/74d3dc78f0db
--
nosy: +python-dev
Roundup Robot devnull@devnull added the comment:
New changeset 513bab5cfb18 by Victor Stinner in branch 'default':
Issue #10833: Remove the buffer allocated on the stack, it isn't used anymore
http://hg.python.org/cpython/rev/513bab5cfb18
New changeset 4c2135930882 by Victor Stinner in branch
STINNER Victor victor.stin...@haypocalc.com added the comment:
I am working with Python since 5 years (and on Python since 3 years): I never
seen any garbage string in error messages. My concern is to not truncate
strings in error messages anymore. I consider that it is more important than
STINNER Victor victor.stin...@haypocalc.com added the comment:
History of PyErr_Format():
- r7580 (13 years ago): creation of PyErr_Format() using a buffer of 500 bytes
(fixed size buffer, allocated on the stack)
- r17159 (10 years ago): PyErr_Format() allocates a dynamic buffer on the heap
Eric Smith e...@trueblade.com added the comment:
I don't feel strongly one way or the other about it. I was just relaying the
reason I heard when I asked the question about why it's done the way it is.
I suggest mentioning that you're going to commit this change on python-dev,
since this
Ray.Allen ysj@gmail.com added the comment:
see also #7330, I'm implementing %.100s in that issue.
--
nosy: +ysj.ray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10833
___
STINNER Victor victor.stin...@haypocalc.com added the comment:
belopolsky Limiting field width when formatting error messages is
belopolsky a good safety measure.
The problem is that PyUnicode_FromFormatV() doesn't support %.100s format (it
ignores .100). If we truncate at 100 bytes, it may
STINNER Victor victor.stin...@haypocalc.com added the comment:
I am concerned about conditions that are impossible in a valid
program. However, if you have a buffer overflow that trashes your
tp_name pointer so that it suddenly resolves to a binary code section,
Yes, %.100s may avoid a
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
I agree with Eric. Limiting field width when formatting error messages is a
good safety measure. It is not only the amount of garbage that can be spitted
in error logs, if garbage is not null-terminated, you may get a
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
/* Caller is responsible for limiting the format */
Note that it is a good idea to avoid memory allocation during exception
processing. Think of out of memory errors: how would you report those if you
need more memory
STINNER Victor victor.stin...@haypocalc.com added the comment:
eric I always thought that one of the reasons for specifying the length
eric was in case a pointer pointed to garbage: at least you'd be limiting
eric how much trash was printed.
No, it's because of the old (removed) 500 bytes
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Thu, Jan 6, 2011 at 3:49 PM, STINNER Victor rep...@bugs.python.org wrote:
..
eric I always thought that one of the reasons for specifying the length
eric was in case a pointer pointed to garbage: at least you'd be
Eric Smith e...@trueblade.com added the comment:
I always thought that one of the reasons for specifying the length was in case
a pointer pointed to garbage: at least you'd be limiting how much trash was
printed. But maybe that's just my imagination and there is no such reason.
--
New submission from STINNER Victor victor.stin...@haypocalc.com:
Guido created the convenience function PyErr_Format() 13 years ago (r7580)
with a naive implementation using char buffer[500] and vsprintf(). He added a
comment:
/* Caller is responsible for limiting the format */
Ok, that was
STINNER Victor victor.stin...@haypocalc.com added the comment:
use_format.patch is a patch to avoid PyOS_snprintf() with a fixed buffer: use
directly PyUnicode_FromFormat(), PyErr_Format() or PySys_FormatStderr()
instead. This patch is just a draft, it should be tested :-) There are other
STINNER Victor victor.stin...@haypocalc.com added the comment:
Woops, I didn't want to do it, but I already commited the simple part of this
issue (U format, eg. %.100U): r87753.
--
___
Python tracker rep...@bugs.python.org
18 matches
Mail list logo
