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 <julianf...@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 >
