On Dec 17, 2007 9:07 PM, <kmradke@rockwellcollins.com> wrote:
> "Erik Huelsmann" <ehuels@gmail.com> wrote on 12/17/2007 04:59:58 AM:
> > The buffer size comes from BUFSIZ which is used to copy files in APR.
> > They probably use BUFSIZ because the definition of the constant is
> > that it should return a buffer size for efficiently doing file IO.
> >
> > Probably the CRT he's using is defining BUFSIZ to 512... (Which I
> > agree, is quite small...)
>
> Thanks for the pointers. I was wondering if it could be an APR issue.
>
> I haven't yet verified, but I assume the windows command line client is
> compiled with visual studio, which would use the standard Microsoft C
> runtime.
You are on the wrong track here.The problem is not what BUFSIZ is
defined on the different platforms but how APR uses it.
BUFSIZ is the size of the buffer that can be set for buffered streams
with the setbuf() call. Nothing more. MSDN just says: "BUFSIZ is the
required user-allocated buffer for the setvbuf routine." BUFSIZ is NOT
a suggestion for a buffer size when dealing with large binary files.
So the bug is in APR where BUFSIZ is used for something it was not designed for.
This has already been discussed for years on this list, but nothing has changed:
http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=82087
http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=113549
So it is clearly an apr and not a windows issue.
Norbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 18 10:50:51 2007