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

Re: translation issue with r28368

From: Arfrever Frehtes Taifersar Arahesis <arfrever.fta_at_gmail.com>
Date: 2007-12-18 17:01:46 CET

2007-12-18 13:57 Fabien COELHO <fabien@coelho.net> napisaƂ(a):
>
> Dear Karl,
>
> sh> svn diff --revision 28367:28368 svntrunk/subversion/libsvn_repos/reporter.c
> Index: svntrunk/subversion/libsvn_repos/reporter.c
> ===================================================================
> --- svntrunk/subversion/libsvn_repos/reporter.c (revision 28367)
> +++ svntrunk/subversion/libsvn_repos/reporter.c (revision 28368)
> @@ -157,6 +157,18 @@
> char *buf;
>
> SVN_ERR(read_number(&len, temp, pool));
> +
> + /* Len can never be less than zero. But could len be so large that
> + len + 1 wraps around and we end up passing 0 to apr_palloc(),
> + thus getting a pointer to no storage? Probably not (16 exabyte
> + string, anyone?) but let's be future-proof anyway. */
> + if (len + 1 < len)
> + {
> + return svn_error_createf(SVN_ERR_REPOS_BAD_REVISION_REPORT, NULL,
> + _("Invalid length (%" APR_UINT64_T_FMT ") "
> + "when about to read a string"), len);
> + }
>
> The above use of _ and of a compilation-time dependent macro is not a good
> idea for the translation. I'm not sure how best to handle this...
>
> # ../libsvn_repos/reporter.c:168: warning: Although being used in a format
> # string position, the msgid is not a valid C format string. Reason: The
> # string ends in the middle of a directive.
>
> On the other hand, I think that it is very unlikely that this error will
> be ever raised, so the translation is not really needed. :-)
>
> sh> svn log -r 28368 --verbose svntrunk/
> ------------------------------------------------------------------------
> r28368 | kfogel | 2007-12-10 00:37:55 +0100 (Mon, 10 Dec 2007) | 9 lines
> Changed paths:
> M /trunk/subversion/libsvn_repos/reporter.c
>
> * subversion/libsvn_repos/reporter.c
> (read_string): Protect against a highly unlikely wraparound in
> allocation size, for the children's sake.
>
> Found by: Timo Sirainen <tss@iki.fi>
> Review by: glasser
> danderson
> breser

This problem was mentioned some days ago:
http://svn.haxx.se/dev/archive-2007-12/0316.shtml
http://svn.haxx.se/dev/archive-2007-12/0488.shtml

--
Arfrever Frehtes Taifersar Arahesis
Received on Tue Dec 18 17:02:02 2007

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.