Re: [boost] [filesystem] temp_directory_path() behavior on Windows

Subject: Re: [boost] [filesystem] temp_directory_path() behavior on Windows
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-02-04 22:13:31

On 5 Feb 2015 at 15:04, Gavin Lambert wrote:

> > Some time ago I raised with Microsoft the urgent need to bump
> > MAX_PATH in Microsoft libc to something sane like 1024, or god
> > forbid, the actual 32767 that the NT kernel supports. The answer was
> > a definite no as it would be a nightmare of compliance testing with
> > never ending corner case bugs, and this I could believe when you
> > examine the MSVCRT source code. Perhaps their brand new rewritten
> > MSVCRT in VS2015 has significantly improved here.
> 
> That is a chicken-and-egg problem, but it's a different one than what I 
> was thinking of.  (Note that MAX_PATH is defined in the Win32 API, not 
> the CRT.)
> 
> The problem there is that there are too many existing APIs that write 
> into a buffer without being given a buffer size explicitly (caller is 
> expected to make it at least MAX_PATH chars long, function guarantees to 
> not write more than MAX_PATH chars).  This is obviously a problem if the 
> two sides do not agree on the value of MAX_PATH, which would be the case 
> for old application vs. new Windows version if they changed it.
> 
> Similarly there is a lot of existing code that assumes that even in the 
> APIs that do accept a buffer size, when using MAX_PATH as the buffer 
> size the API "cannot" fail with a buffer size error.  (Whether this is 
> good code or not is out of scope -- there's a lot of it in the wild.) 
> These would also do peculiar things if this assumption were violated.
> 
> Making the C/C++ runtime support extended paths would definitely be a 
> step forward, but it's still very common to completely sidestep the CRT 
> and go straight to the WinAPI, because it has more features.

Sure. I was referring to the MSVCRT only. Basically iostreams and 
fopen() etc should work with extended paths. I wouldn't try modifying 
win32.

Except actually, I would. I'd add a new type of unicode string for 
file paths (only allocatable using an AllocateFilePath() function) 
and a new extension for win32 APIs e.g. CreateFileLW. I'd have all LW 
ending functions check the string being fed to them, and if not 
allocated by AllocateFilePath() then abort. That should trap 
applications being converted over from legacy wchar_t who do C 
casting to TCHAR.

New applications can then use the LW extended APIs, and we get long 
path support in Windows at long last. Simples! :)

Niall
-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/