Re: Design for a file system library

From: dylan_nicholson (dylan_nicholson_at_[hidden])
Date: 2002-03-05 18:22:43

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 03:08 AM 2/26/2002, Jan Langer wrote:
> 
> At 08:43 AM 2/26/2002, Jan Langer wrote:
> 
> 
> I've been thinking a lot about Jan's two messages above, and I'm 
convinced 
> he has identified a serious weakness.  We don't want any trap doors 
that 
> allow access to the current working directory.
> 
> (Rationale: "current working directory" is in effect a global 
variable. For 
> why that is a serious problem, put "global variables considered 
harmful" 
> into Google.)
> 
But "Current working directory" is not really a global variable, it's 
an operating system concept, just as "active window", "currently 
logged in user" etc. are.
While I agree it's generally better to write code that uses absolute 
paths where possible (mainly because using the wd is not thread-
safe), you can't always avoid needing to know it.
For one thing certain third party libraries either a) silently change 
the working directory or b) require it to be set correctly to work.
A good example of a) is the Win32 ::GetOpenFileName call that 
displays a dialog box allowing you to choose a file.  By default it 
changes the working directory, so that the next time you call it 
starts up in the same directory.  If absolute(...) didn't make use of 
the correct current directory (as opposed to the initial working 
directory when the application started), then code like:

OPENFILENAME ofn;
/* fill in ofn structure */
::GetOpenFileName(ofn);
name = absolute(ofn.lpstrFileTitle);

would unexpectedly not work (I don't want to use GetFullPathName, 
because it is a pain to call).

I have seen examples of b) that are inhouse legacy libraries that for 
one reason or another are too hard to change.  So for these 
situations I need to be able to set the working directory.

I really don't see what going out of your way to "ban" users from 
accessing this is supposed to achieve.

Btw no-one has yet answered my concerned about supporting passing 
char* and wchar_t* strings to file system functions.  If the only 
forms available are templated on basic_string this isn't possible 
without explicitly creating the string yourself, meaning the above 
would be:

name = absolute(std::basic_string<TCHAR>(ofn.lpstrFileTitle));

assuming I wanted to be able to compile my application as Unicode or 
non-Unicode (we still write a lot of software like this).

Dylan