Author vstinner
Recipients amaury.forgeotdarc, belopolsky, eric.smith, vstinner
Date 2011-01-06.20:49:10
SpamBayes Score 0.000151774
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