Hi Julian,
> This bug occurred because the "%ld" format and/or the 'long' data type
were 32-bit. This is indeed the case:
> On 64-bit Windows, 'long' is a 32-bit type (and 'long long' is 64-bit; on
most other platforms both are 64-bit.)
Ok, that explains it. I did not know that 'long' is 32 bits on 64-bit
Windows. Most of my experience with C is on embedded systems where we use
specific integer sizes (like C99 stdint.h types).
Thanks!
Regards,
Ronald
On Thu, Nov 23, 2017 at 12:17 PM, Julian Foad <julianfoad_at_apache.org> wrote:
> Ronald Taneza wrote:
>
>> Hi Julian,
>>
>> Thank you for your quick response and patch. I hope that this is fixed in
>> the next 1.8.x release and that CollabNet will also release an update to
>> Subversion Edge.
>>
>
> It should be.
>
> I'm still not so clear how this is exactly a problem with svnrdump 1.8.19
>> (from Subversion Edge). This is my first time browsing through the svn
>> source code, and I hope you'll indulge me with my questions below.
>>
>> We are using Subversion Edge 5.2.2 (Windows 64-bit) on a Windows Server
>> 2012 (64-bit) OS.
>>
>
> This bug occurred because the "%ld" format and/or the 'long' data type
> were 32-bit. This is indeed the case:
>
> On 64-bit Windows, 'long' is a 32-bit type (and 'long long' is 64-bit; on
> most other platforms both are 64-bit.)
>
> ( https://stackoverflow.com/questions/384502/what-is-the-bit-
> size-of-long-on-64-bit-windows#384672 )
>
> I also verified that the httpd.exe, svn.exe, and svnrdump.exe binaries are
>> 64-bit. (I ran the "file xxx" command in Cygwin and also checked their PE
>> signatures as described here: https://superuser.com/question
>> s/358434/how-to-check-if-a-binary-is-32-or-64-bit-on-windows).
>>
>> You mentioned:
>>
>> > SVN_ERR(svn_stream_printf(eb->stream, pool,
>> SVN_REPOS_DUMPFILE_CONTENT_LENGTH
>> ": %ld\n\n",
>> (unsigned long)info->size +
>> propstring->len));
>>
>> > info->size is apr_off_t ... probably 64 bits on most systems.
>> > propstring->len is apr_size_t ... probably 64 bits on most systems.
>>
>
> I was wrong about that: apr_size_t would be 32-bit on 32-bit
> architectures. File sizes (apr_off_t) are more likely to be 64-bit,
> although there may be some platforms where they are 32-bit, maybe depending
> on compile-time options or something that is configurable.
>
> Therefore my initial patch (changing to use APR_SIZE_T_FMT) was wrong
> (would not have worked on 32-bit architectures). I have now corrected that
> to use APR_OFF_T_FMT.
>
> > It uses "%lu" for the text content, which thus work OK up to 4 GB, and
>> "%ld" for the overall content length which thus only works up to 2 GB.
>>
>
> When I wrote that, I was assuming a 32-bit architecture.
>
> On a 64-bit system where unsigned long is uint64:
>>
>
> On a standard Windows-64 system, it's not.
>
> I hope that clears up the issue.
>
> - Julian
>
Received on 2017-11-23 13:57:26 CET