[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: "format not a string literal" warnings

From: Greg Stein <gstein_at_gmail.com>
Date: Mon, 10 Nov 2008 06:35:09 -0800

When I've turned up the error reporting, I've seen those warnings,
too. It also happens when we do something like:

printf(timedate_format, arg1, arg2);

You can't do much about those. But for constructs like you pointed
out: definitely, let's add the "%s". It is much safer to use that over
the lifetime of the code. Who knows where the argument might come from
next week.


On Mon, Nov 10, 2008 at 5:36 AM, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> Hi all.
> Since getting rid of the deprecated warnings, I've noticed a new set of warnings
> showing themselves to me. This is with gcc 4.3.2 on Ubuntu Intrepid. For example:
> subversion/svnlook/main.c: In function 'print_diff_tree':
> subversion/svnlook/main.c:967: warning: format not a string literal and no
> format arguments
> subversion/svnlook/main.c:986: warning: format not a string literal and no
> format arguments
> These happen where we use code constructs such as:
> SVN_ERR(svn_cmdline_printf(pool, header->data));
> The concern here is that the variable could be untrusted and this could have
> security implications. The "proper" way to do this is:
> SVN_ERR(svn_cmdline_printf(pool, "%s", header->data));
> Now, in lots of cases the string we're directly printing is completely
> internally generated, so this is just an extra step (albeit one which silences a
> warning). In other cases, this may be legitimately required. However, instead
> of taking the time to audit the code and make the distinction, and for
> consistency's sake, we may just want change all these calls to use an explicit
> format string.
> Thoughts?
> -Hyrum

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-10 15:35:34 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.