This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients amaury.forgeotdarc, belopolsky, eric.smith, vstinner, ysj.ray
Date 2011-03-03.09:31:09
SpamBayes Score 1.5341808e-08
Marked as misclassified No
Message-id <1299144670.05.0.140938015947.issue10833@psf.upfronthosting.co.za>
In-reply-to
Content
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
 - r22722 (9 years ago): PyErr_Format() reuses PyString_FromFormatV() (dynamic buffer, allocated on the heap)

belopolsky>> Limiting field width when formatting error messages
belopolsky>> is a good safety measure.

me> Can you give me at least one example? I think that it is very
me> unlikely, or just impossible.

Python allocates a dynamic buffer since r17159 (10 years ago), and the strings were *never* truncated just because %.100s format was never supported (it is interpreted as %s).

If you still consider that %.100s protects is a good solution against crashes: you have to realize that Python doesn't truncate strings since 10 years, and nobody complained.

--

The situation is changing because Ray Allen wrote a patch implementing %.100s: #7330. I would like to decide what to do with %.100s in error messages before commiting #7330.

--

Eric and Alexander: do you still consider that %.100s is important in error messages? Or do you know agree that we can replace them with %s?
History
Date User Action Args
2011-03-03 09:31:10vstinnersetrecipients: + vstinner, amaury.forgeotdarc, belopolsky, eric.smith, ysj.ray
2011-03-03 09:31:10vstinnersetmessageid: <1299144670.05.0.140938015947.issue10833@psf.upfronthosting.co.za>
2011-03-03 09:31:09vstinnerlinkissue10833 messages
2011-03-03 09:31:09vstinnercreate