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

Subject: Re: [boost] [filesystem] temp_directory_path() behavior on Windows
From: Domagoj Saric (domagoj.saric_at_[hidden])
Date: 2015-02-16 04:49:12

On 4.2.2015. 16:08, Niall Douglas wrote:
> On 4 Feb 2015 at 14:55, Domagoj Saric wrote:
>
>>> It would have to be a very borked situation if one of those didn't
>>> work.
>>
>> Considering that:
>>
>> 1) GetTempPath() is not deprecated (which I would take to mean that the
>> 'manufacturer of the OS' holds this function to be sufficient for 'most users')
>
> That's a reasonable point. Apart from its hardcoded 260 char limit.

I can concede that the 260 >byte< limit is problematic (and probably a bug on MS 
side) and that Boost.FS can offer a workaround (for wchar_t based code) by 
reimplementing the officially described logic of GetTempPath()...

>> 2) Boost.FS is already more than bloated
>
> I certainly wouldn't call Filesystem bloated! If anything, it verges
> on being so lightweight as to not be sufficiently useful for many
> common tasks

By bloated I didn't refer to its feature set (features and options coded so that 
they obey the "you don't pay for it if you don't use it" rule are "power" not 
"bloat" in my book) more about its implementation or "binary bloat" or being the 
next "iostreams" when it gets into the standard :/
http://lists.boost.org/Archives/boost/2011/08/184823.php
Didn't personally look at it for years, but when I did, I found it doing things 
like constructing std::strings out of C strings just so that it can call 
find_first_of() on them "for crying out loud"...It's 'careless' use of STL 
containers and all the inivisible EH baggage this creates, etc...
With that approach C++ will never be widely accepted as the 'one true all 
purpose language' (e.g. would you really use iostreams, filesystem or even 
std::function in the kernel of 'the next great OS'?)...

Note that this is especially problematic on Windows that does not have a 
standard prebuilt/included C++ library so most people resort to linking 
statically with the CRT (which with Boost.FS brings in a ton of code)...Kind of 
'embarassing' that a hello world Boost.FS console program will weigh in hundreds 
of kilobytes...

>> ...I would 'like' that the default implementation stays "as simple as possible
>> but not simpler" and add a separate function or set of functions for the various
>> special and edge cases. For example you could add a FindFile-like API that would
>> give you a token with which it would allow you to iterate possible temp. paths
>> until a working one is found [if the one returned in the last call isn't useable
>> you'd call something like get_next_temp( current_temp_path_iteration_state
>> );]...and/or you could provide the same with a container/begin-end interface...
>
> Sounds like a recipe for racy temp file code with security holes.

Honestly, how's that?

-- 
Domagoj Saric
Software Architect
www.LittleEndian.com