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-16 06:25:09

On 16 Feb 2015 at 10:44, Domagoj Saric wrote:

> > Not at all. Think about thin clients which have virtually no local
> > storage, and exclusively boot from the network. They're very common
> > in everything from schools to government.
> 
> They run Windows on these thin clients w/o virtual memory?

The NT kernel has been capable of running inside a fixed memory 
allocation since its inception. On Windows Phone for example, the 
kernel has exactly 160Mb, no more, no less. "Windows for Warships" 
from the 1990s had a fixed memory allocation. Cash ATMs running 
Windows similarly so. And so on.

So the answer is yes. Remember the applications available tend to be 
very limited, basically Office, Internet Explorer and a few 
proprietary apps. You certainly can't install anything, and you 
usually can't run more than two apps at a time.

> Of course library developers are called to make judgment calls on 
what's 'sane' 
> when modeling a given system...
> 
> In the same vein, TEMP and TMP are system 'prescribed' variables 
which are 
> supposed to exist. If they don't, the system is broken "and it's 
not really a 
> call for Boost" to bloat everybodies binaries trying to workaround 
this 
> hypothetical situation.

As I mentioned, Win32 services are often run with no environment 
variables. And launching a child process on Windows using 
Boost.Process will more often than not unintentionally give the child 
an empty environment due to quirks.

And what bloat is there here? A few opcodes at most. Come back to 
when there are megabytes of bloat, then I might care.

> >> 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...

It seems to me all that goes away if Filesystem becomes header only.

> 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'?)...

There are many reasons why C++ shoots itself in the foot as a systems 
programming language - particularly in its poor ABI management. I 
also greatly dislike its haughty attitude to being more friendly to 
system programming consumers like language runtimes where we as a 
community often seem to go out of out way to build ourselves C++ only 
ivory towers where it really wouldn't kill us to think slightly 
bigger, especially where the consequences on the C++ are negligible.

However are any of the items you mentioned are not an issue in a next 
gen OS platform. My current client happens to be building a next gen 
OS platform, and they use all three of your items very extensively. 
Are these uses without problem? No, not at all ... but they are 
better than the alternatives. As warty as especially iostreams is, it 
is very well tested, behaves predictably on all platforms, and the 
average C++ engineer you interview doesn't need to be trained up in 
its use, which is a rare thing for most C++ technologies.

> 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...

Thankfully VS2015 finally kills off the static MSVCRT. You'll get 
DLLs and DLLs only from VS2015 onwards, and it's long overdue IMHO. 
See 
http://blogs.msdn.com/b/vcblog/archive/2014/06/10/the-great-crt-refact
oring.aspx.

> >> ...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?

Any iterator based filesystem parser is racy by definition. Only 
snapshot based filesystem parsing has some chance of not being racy.

My single biggest issue with Filesystem is the lack of hard 
guarantees for raciness. I think for each and every API guarantees 
need to be stated just as you would give complexity guarantees and 
exception guarantees. Even if the guarantee is "this API is 
completely useless when the filing system is changing".

For the record, I'm eating my own breakfast on this, and the v1.3 
AFIO release will contain a long document providing race guarantees 
per supported platform. I'll admit that preparing this document is 
very tedious. On the other hand, I've discovered a wealth of race 
bugs in AFIO (and POSIX) as a result, in fact last night I lodged a 
bug with FreeBSD as they are particularly borked due to having no way 
of fetching the current path of an open file descriptor (and being 
the only major OS not to have that).

Niall

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