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
> when modeling a given system...
> In the same vein, TEMP and TMP are system 'prescribed' variables
> 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
> 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.
> >> ...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).
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/