On Tue, Apr 28, 2015 at 2:23 AM Johannes Schindelin
johannes.schinde...@gmx.de wrote:
Hi Peff,
On 2015-04-28 08:02, Jeff King wrote:
My understanding is that PATH_MAX is set absurdly low on Windows
systems (and doesn't actually represent the real limit of a path!).
Well, yes and no.
Hi,
On 2015-04-28 17:33, Doug Kelly wrote:
If you're able to do everything through the Unicode Win32 APIs, you can reach
65535 characters, assuming the filesystem supports it (NTFS does, FAT32 would
not, for example). I recall there being one function (possibly thinking of
mktemp) that
On Sun, Apr 26, 2015 at 08:49:42AM +0200, Erik Elfström wrote:
read_gitfile_gently will allocate a buffer to fit the entire file that
should be read. Add a sanity check of the file size before opening to
avoid allocating a potentially huge amount of memory if we come across
a large file that
Hi Peff,
On 2015-04-28 08:02, Jeff King wrote:
My understanding is that PATH_MAX is set absurdly low on Windows
systems (and doesn't actually represent the real limit of a path!).
Well, yes and no. Yes, it is absurdly low on Windows, and yes, it is not the
real limit of a path *if you know
On Tue, Apr 28, 2015 at 8:02 AM, Jeff King p...@peff.net wrote:
My understanding is that PATH_MAX is set absurdly low on Windows
systems (and doesn't actually represent the real limit of a path!).
Since the value is picked arbitrarily anyway, could use something more
independent (like 100K or
read_gitfile_gently will allocate a buffer to fit the entire file that
should be read. Add a sanity check of the file size before opening to
avoid allocating a potentially huge amount of memory if we come across
a large file that someone happened to name .git. The limit is set to
a sufficiently
6 matches
Mail list logo
