On 29/7/02 3:52 PM, "cmpilato@collab.net" <cmpilato@collab.net> wrote:
> sussman@tigris.org writes:
>
>> Author: sussman
>> Date: 2002-07-29 14:22:29 -0500 (Mon, 29 Jul 2002)
>> New Revision: 2772
>>
>> Modified:
>> trunk/subversion/libsvn_repos/dump.c
>> Log:
>>
>> Dumper bugfix from William Uther <will+@cs.cmu.edu>.
>>
>> * dump.c (dump_node):
>> Apparently on his Mac OS X box, the Prop-content-length: was being
>> printf'ed as a '0', even though gdb clearly showed that its value
>> was 10. That's what happens when you mix up your apr_off_t's with
>> your apr_size_t's, and choose the wrong *_FMT printf macro.
>
> William, can you explain something please? I'm trying to figure out
> why, instead of just making TEXTLEN, PROPLEN, and CONTENT_LENGTH all
> apr_size_t or apr_off_t, you swapped the types used for PROPLEN and
> CONTENT_LENGTH? It would seem that we should just use apr_off_t or
> apr_size_t for all three values.
Here is the explanation I had in my email with the patch:
> There were two problems. The obvious bug was that apr_off_t variables
> were being printed using APR_SIZE_T_FMT. The less obvious bug was that
> proplen was using apr_off_t when the prop string is stored in memory
> (unnecessary), and also content_length was only apr_size_t when it needs to
> hold both textlen and proplen. As textlen is (correctly) apr_off_t,
> content_length needs to be apr_off_t too.
To elaborate a bit, textlen is copied in blocks from the repos. This code
should work even when the text of the file is too large to fit in an
apr_size_t. The property code dumps the properties to a string in memory,
hence apr_size_t is all that is needed.
Yes, you could make them all one or the other. If you choose apr_size_t
then you've lost the ability to handle large files (which may not matter as
other code already has that limit?). If you choose apr_off_t then proplen
is larger than it needs to be, but that's not a major issue.
\x/ill :-}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 29 22:19:18 2002