[resending to cc dev@ list and remove svn@]
That's not portable. The following program
#include <apr_general.h>
#include <apr_strings.h>
#include <apr_pools.h>
int main()
{
apr_initialize();
apr_uint64_t ulen = 123;
apr_int64_t slen = -123;
apr_pool_t *pool;
apr_pool_create(&pool, NULL);
puts(apr_psprintf(pool, "%" APR_UINT64_T_FMT, ulen));
puts(apr_psprintf(pool, "%llu", ulen));
puts(apr_psprintf(pool, "%" APR_INT64_T_FMT, slen));
puts(apr_psprintf(pool, "%lld", slen));
exit(1);
}
On Centos 4, gcc 3.4.3, i386 prints:
123
123
-123
-123
On Centos 4, gcc 3.4.3, x86_64 prints:
123
%lu
-123
%ld
this is against apr-1. So you need the APR_UINT64_T_FMT to handle this and use
the appropriate format string.
Regards,
Blair
Dongsheng Song wrote:
> Could you use "llu" instead of "APR_UINT64_T_FMT", otherwise:
>
> $ ../../tools/po/po-update.sh zh_CN
> Building subversion.pot...
> ../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.
>
> Dongsheng
>
> 2007/12/10, kfogel@tigris.org <kfogel@tigris.org>:
>> Author: kfogel
>> Date: Sun Dec 9 15:37:55 2007
>> New Revision: 28368
>>
>> Log:
>> * 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
>>
>>
>> Modified:
>> trunk/subversion/libsvn_repos/reporter.c
>>
>> Modified: trunk/subversion/libsvn_repos/reporter.c
>> URL: http://svn.collab.net/viewvc/svn/trunk/subversion/libsvn_repos/reporter.c?pathrev=28368&r1=28367&r2=28368
>> ==============================================================================
>> --- trunk/subversion/libsvn_repos/reporter.c (original)
>> +++ trunk/subversion/libsvn_repos/reporter.c Sun Dec 9 15:37:55 2007
>> @@ -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);
>> + }
>> +
>> buf = apr_palloc(pool, len + 1);
>> SVN_ERR(svn_io_file_read_full(temp, buf, len, NULL, pool));
>> buf[len] = 0;
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: svn-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: svn-help@subversion.tigris.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: svn-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: svn-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 15 02:33:14 2007