On Monday 15 March 2010 01:10:10 Andrey Semashev wrote:
On 03/15/2010 12:50 AM, Vladimir Prus wrote:
On Sunday 14 March 2010 23:37:06 Scott McMurray wrote:
On 14 March 2010 15:21, Tom Brinkman<reportbase2007@gmail.com> wrote:
The printf style parameters is responsible for thousands and thousands of security vulnerabilities.
Just plain wrong.
Some evidence for your position would be good, since it's trivial to find documentation of holes from printf-style parameters: http://en.wikipedia.org/wiki/Format_string_attack
I don't think that's hole from printf-style parameters. By reading that page it's trivial to notice that it's the %n format specifier -- which actually writes something into program -- is the key component of attack. Clearly a printf-like function that does not support any way to modify program state is safe. Am I missing something?
You do understand that the use of ellipsis is error-prone, even if it doesn't lead to program modification, do you?
Error prone in what way? That you can pass integer for %s and get garbage? Well, good compilers tend to help: a.c:12: warning: format ‘%s’ expects type ‘char*’, but argument 2 has type ‘int’ And even without compiler help, a tradeoff between convenience and accidental bug is a valid tradeoff. Saying that elipsis is a no-no seems a bit too much.
It is common knowledge that sprintf-like functions are often misused, which results in buffer overruns
Uhm. You cannot have buffer overrun if you don't have a buffer, don't you think? I don't think anybody suggests that boost.log sprintfs anything into a fixed-size buffer.
or incorrect arguments being passed. In C++, the problem of accidental passing of non-POD typed arguments is added.
For all I know, there's no such problem: a.c:19: warning: cannot pass objects of non-POD type ‘struct S’ through ‘...’; call will abort at runtime Of course, some folks ignore warnings, but well, they probably have bigger problems. - Volodya