Subject: Re: [boost] [build] File / path lengths difficult to manage on Windows
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-11-13 21:13:37
On 14/11/2013 14:31, Quoth Ben Craig:
> I think this is being unrealistic. If we take this approach, then you
> should request every Win32 program that uses fopen, iostreams, or
> CreateFile without the magic marker to change their program to use a
> non-portable API. This includes programs like cmd.exe, explorer,
> bjam, 7zip, and countless others.
Did you mean to quote someone else? Because I was agreeing with you.
> I wish that "normal" Windows APIs permitted a higher maximum path
> length, but they don't. Reasonable Windows support means
> acknowledging this limitation.
It's unfortunately a wart of its DOS outgrowth. Back in the days of 8.3
filename limits a total path length of 260 was ample, and most of the
early DOS APIs were based around local stack buffers of [MAX_PATH].
This has ended up getting carried forward via backwards-compatibility,
because the APIs don't provide any way to accept the buffer size
explicitly and it can't be increased arbitrarily without crashing older
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk