homepage

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
Date 2011年01月06日.20:49:10
SpamBayes Score 0.00015177447
Marked as misclassified No
Message-id <1294346956.83.0.829438107968.issue10833@psf.upfronthosting.co.za>
In-reply-to
Content
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 limit.
There are different types of %s arguments:
 - name of a type, eg. PyType(op)->tp_name
 - constant message (a switch/case or if chose between different messages)
 - function/method name
 - ...
 - and sometimes an argument from the user, eg. codec.lookup(name) repeats the name in the result
belopolsky> Limiting field width when formatting error messages
belopolsky> is a good safety measure. It is not only the amount
belopolsky> of garbage that can be spitted in error logs, if garbage
belopolsky> is not null-terminated, ...
Can you give me at least one example? I think that it is very unlikely, or just impossible. But if I do replace "%.100s" by "%s" in all the code base, I accept to check each time that the argument is null-terminated and/or not controlable by the user. And maybe keep "%.100s" if I am not sure.
belopolsky> Think of out of memory errors: ...
PyErr_NoMemory() doesn't use PyErr_Format(), it's message is fixed, and the exception object is preallocated.
History
Date User Action Args
2011年01月06日 20:49:16vstinnersetrecipients: + vstinner, amaury.forgeotdarc, belopolsky, eric.smith
2011年01月06日 20:49:16vstinnersetmessageid: <1294346956.83.0.829438107968.issue10833@psf.upfronthosting.co.za>
2011年01月06日 20:49:10vstinnerlinkissue10833 messages
2011年01月06日 20:49:10vstinnercreate

AltStyle によって変換されたページ (->オリジナル) /