Message125586
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. |
|
| Date |
User |
Action |
Args |
| 2011-01-06 20:49:16 | vstinner | set | recipients:
+ vstinner, amaury.forgeotdarc, belopolsky, eric.smith |
| 2011-01-06 20:49:16 | vstinner | set | messageid: <[email protected]> |
| 2011-01-06 20:49:10 | vstinner | link | issue10833 messages |
| 2011-01-06 20:49:10 | vstinner | create | |
|