Message125586
| 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. |
|