Daniel Näslund wrote:
> Still on the lookout for something interresting. In the meantime I've
> started removing some compiler warnings.
>
> The code looks uglier but the warnings is gone.
A statement like that is a red flag to me. We are not slaves to the
warnings; we should only use them as a hint to try to write "better"
code.
> Is there any #directive
> to ignore warnings for a subpart of the code? We know that those fmt
> strings are safe. Perhaps we could tell the compiler that?
That would be better than writing ugly code, but probably not necessary.
> [[[
> * subversion/libsvn_client/diff.c
> (display_prop_diffs): Remove warnings about 'format not a string
> literal'.
>
> * subversion/libsvn_client/export.c
> (copy_one_versioned_file): Remove warnings about 'format not a string
> literal'.
>
> Patch by: Daniel Näslund <daniel_at_longitudo.com>
> ]]]
For this bit:
> if (! original_value)
> - header_fmt = _("Added: %s%s");
> + SVN_ERR(file_printf_from_utf8(file, encoding, "Added: %s%s",
> + propchange->name, APR_EOL_STR));
> else if (! propchange->value)
> - header_fmt = _("Deleted: %s%s");
> + SVN_ERR(file_printf_from_utf8(file, encoding, "Deleted: %s%s",
> + propchange->name, APR_EOL_STR));
> else
> - header_fmt = _("Modified: %s%s");
> - SVN_ERR(file_printf_from_utf8(file, encoding, header_fmt,
> + SVN_ERR(file_printf_from_utf8(file, encoding, "Modified: %s%s",
> propchange->name, APR_EOL_STR));
consider writing:
if (! original_value)
action = _("Added");
else if (! propchange->value)
action = _("Deleted");
else
action = _("Modified");
SVN_ERR(file_printf_from_utf8(file, encoding,
"%s: %s" APR_EOL_STR,
action, propchange->name));
and similarly, in the other bit, you could do:
[... suffix = "M" or "" ...]
SVN_ERR(svn_subst_build_keywords2
(&kw, keywords->data,
- apr_psprintf(scratch_pool, fmt, changed_rev),
+ apr_psprintf(scratch_pool, "%ld%s",
+ changed_rev, suffix),
entry->url, tm, author, scratch_pool));
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2414666
Received on 2009-11-05 12:20:05 CET