1
0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-10 09:58:01 +00:00
putty-source/windows/utils/request_file.c

115 lines
3.1 KiB
C
Raw Normal View History

/*
* GetOpenFileName/GetSaveFileName tend to muck around with the process'
* working directory on at least some versions of Windows.
* Here's a wrapper that gives more control over this, and hides a little
* bit of other grottiness.
*/
#include "putty.h"
struct filereq_tag {
TCHAR cwd[MAX_PATH];
WCHAR wcwd[MAX_PATH];
};
/*
* `of' is expected to be initialised with most interesting fields, but
* this function does some administrivia. (assume `of' was memset to 0)
* save==1 -> GetSaveFileName; save==0 -> GetOpenFileName
* `state' is optional.
*/
bool request_file(filereq *state, OPENFILENAME *of, bool preserve, bool save)
{
TCHAR cwd[MAX_PATH]; /* process CWD */
bool ret;
/* Get process CWD */
if (preserve) {
DWORD r = GetCurrentDirectory(lenof(cwd), cwd);
if (r == 0 || r >= lenof(cwd))
/* Didn't work, oh well. Stop trying to be clever. */
preserve = false;
}
/* Open the file requester, maybe setting lpstrInitialDir */
{
#ifdef OPENFILENAME_SIZE_VERSION_400
of->lStructSize = OPENFILENAME_SIZE_VERSION_400;
#else
of->lStructSize = sizeof(*of);
#endif
of->lpstrInitialDir = (state && state->cwd[0]) ? state->cwd : NULL;
/* Actually put up the requester. */
ret = save ? GetSaveFileName(of) : GetOpenFileName(of);
}
/* Get CWD left by requester */
if (state) {
DWORD r = GetCurrentDirectory(lenof(state->cwd), state->cwd);
if (r == 0 || r >= lenof(state->cwd))
/* Didn't work, oh well. */
state->cwd[0] = '\0';
}
/* Restore process CWD */
if (preserve)
/* If it fails, there's not much we can do. */
(void) SetCurrentDirectory(cwd);
return ret;
}
/*
* Here's the same one again, the wide-string version
*/
bool request_file_w(filereq *state, OPENFILENAMEW *of,
bool preserve, bool save)
{
WCHAR cwd[MAX_PATH]; /* process CWD */
bool ret;
/* Get process CWD */
if (preserve) {
DWORD r = GetCurrentDirectoryW(lenof(cwd), cwd);
if (r == 0 || r >= lenof(cwd))
/* Didn't work, oh well. Stop trying to be clever. */
preserve = false;
}
/* Open the file requester, maybe setting lpstrInitialDir */
{
of->lStructSize = sizeof(*of);
of->lpstrInitialDir = (state && state->wcwd[0]) ? state->wcwd : NULL;
/* Actually put up the requester. */
ret = save ? GetSaveFileNameW(of) : GetOpenFileNameW(of);
}
/* Get CWD left by requester */
if (state) {
DWORD r = GetCurrentDirectoryW(lenof(state->wcwd), state->wcwd);
if (r == 0 || r >= lenof(state->wcwd))
/* Didn't work, oh well. */
state->wcwd[0] = L'\0';
}
/* Restore process CWD */
if (preserve)
/* If it fails, there's not much we can do. */
(void) SetCurrentDirectoryW(cwd);
return ret;
}
filereq *filereq_new(void)
{
Rename 'ret' variables passed from allocation to return. I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no longer fond of the variable name 'ret', because it's used in two quite different contexts: it's the return value from a subroutine you just called (e.g. 'int ret = read(fd, buf, len);' and then check for error or EOF), or it's the value you're preparing to return from the _containing_ routine (maybe by assigning it a default value and then conditionally modifying it, or by starting at NULL and reallocating, or setting it just before using the 'goto out' cleanup idiom). In the past I've occasionally made mistakes by forgetting which meaning the variable had, or accidentally conflating both uses. If all else fails, I now prefer 'retd' (short for 'returned') in the former situation, and 'toret' (obviously, the value 'to return') in the latter case. But even better is to pick a name that actually says something more specific about what the thing actually is. One particular bad habit throughout this codebase is to have a set of functions that deal with some object type (say 'Foo'), all *but one* of which take a 'Foo *foo' parameter, but the foo_new() function starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the canonical name for the ambient Foo is 'foo', so should foo_new()! So here's a no-brainer start on cutting down on the uses of 'ret': I looked for all the cases where it was being assigned the result of an allocation, and renamed the variable to be a description of the thing being allocated. In the case of a new() function belonging to a family, I picked the same name as the rest of the functions in its own family, for consistency. In other cases I picked something sensible. One case where it _does_ make sense not to use your usual name for the variable type is when you're cloning an existing object. In that case, _neither_ of the Foo objects involved should be called 'foo', because it's ambiguous! They should be named so you can see which is which. In the two cases I found here, I've called them 'orig' and 'copy'. As in the previous refactoring, many thanks to clang-rename for the help.
2022-09-13 13:53:36 +00:00
filereq *state = snew(filereq);
state->cwd[0] = '\0';
state->wcwd[0] = L'\0';
Rename 'ret' variables passed from allocation to return. I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no longer fond of the variable name 'ret', because it's used in two quite different contexts: it's the return value from a subroutine you just called (e.g. 'int ret = read(fd, buf, len);' and then check for error or EOF), or it's the value you're preparing to return from the _containing_ routine (maybe by assigning it a default value and then conditionally modifying it, or by starting at NULL and reallocating, or setting it just before using the 'goto out' cleanup idiom). In the past I've occasionally made mistakes by forgetting which meaning the variable had, or accidentally conflating both uses. If all else fails, I now prefer 'retd' (short for 'returned') in the former situation, and 'toret' (obviously, the value 'to return') in the latter case. But even better is to pick a name that actually says something more specific about what the thing actually is. One particular bad habit throughout this codebase is to have a set of functions that deal with some object type (say 'Foo'), all *but one* of which take a 'Foo *foo' parameter, but the foo_new() function starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the canonical name for the ambient Foo is 'foo', so should foo_new()! So here's a no-brainer start on cutting down on the uses of 'ret': I looked for all the cases where it was being assigned the result of an allocation, and renamed the variable to be a description of the thing being allocated. In the case of a new() function belonging to a family, I picked the same name as the rest of the functions in its own family, for consistency. In other cases I picked something sensible. One case where it _does_ make sense not to use your usual name for the variable type is when you're cloning an existing object. In that case, _neither_ of the Foo objects involved should be called 'foo', because it's ambiguous! They should be named so you can see which is which. In the two cases I found here, I've called them 'orig' and 'copy'. As in the previous refactoring, many thanks to clang-rename for the help.
2022-09-13 13:53:36 +00:00
return state;
}
void filereq_free(filereq *state)
{
sfree(state);
}