Odd compiler bug or such?
-
I just stumbled upon a very weird problem and I just can't figure out why this happens. Basically the code I am talking about looks like this:
bRet = ToBool(::CreateProcess(
NULL,
strCmdLine.GetBuffer(strCmdLine.GetLength() + 1),
NULL,
NULL,
m_bInheritHandles,
(m_bCreateNewConsole ? CREATE_NEW_CONSOLE : 0),
NULL,
(strCurDir.IsEmpty() ? NULL : strCurDir),
&si,
&m_processInfo
));I think it's pretty clear what it does, and there is nothing special about it. The problem lies in the strCurDir parameter. CreateProcess will fail if the directory you specify doesn't exist or is otherwise invalid. Ok... it exists, that's for sure (there is another function that takes care of this). So I just check if one was specified and pass this one, or NULL otherwise. Pretty simple. Though it doesn't work. Even if the string is empty, something (invalid) is passed to CreateProcess. I suppose that an empty string instead of zero is passed, as I could exclude all other possible problem-sources. Anyone has an idea why this is failing? I added a simple workaround, but still... I'd like to know why it fails.
-
I just stumbled upon a very weird problem and I just can't figure out why this happens. Basically the code I am talking about looks like this:
bRet = ToBool(::CreateProcess(
NULL,
strCmdLine.GetBuffer(strCmdLine.GetLength() + 1),
NULL,
NULL,
m_bInheritHandles,
(m_bCreateNewConsole ? CREATE_NEW_CONSOLE : 0),
NULL,
(strCurDir.IsEmpty() ? NULL : strCurDir),
&si,
&m_processInfo
));I think it's pretty clear what it does, and there is nothing special about it. The problem lies in the strCurDir parameter. CreateProcess will fail if the directory you specify doesn't exist or is otherwise invalid. Ok... it exists, that's for sure (there is another function that takes care of this). So I just check if one was specified and pass this one, or NULL otherwise. Pretty simple. Though it doesn't work. Even if the string is empty, something (invalid) is passed to CreateProcess. I suppose that an empty string instead of zero is passed, as I could exclude all other possible problem-sources. Anyone has an idea why this is failing? I added a simple workaround, but still... I'd like to know why it fails.
And what did
GetLastError()
returned?nave [OpenedFileFinder]
-
And what did
GetLastError()
returned?nave [OpenedFileFinder]
267, Invalid directory. I know that the problem is the passed directory; setting it to NULL "fixes" the problem. Trust me that I pinned it down as much as I could and excluded any other possible problems.
-
267, Invalid directory. I know that the problem is the passed directory; setting it to NULL "fixes" the problem. Trust me that I pinned it down as much as I could and excluded any other possible problems.
Could you pass that directory to the PathFileExists() function and check what it returned?
nave [OpenedFileFinder]
-
Could you pass that directory to the PathFileExists() function and check what it returned?
nave [OpenedFileFinder]
As I said, the string is empty. A previous function, which is used to set the directory variable, checks whether the directory exists or not and empties the string otherwise. Again, I excluded all possible problem sources - it is just not "that easy". I still believe that it is a compiler bug (and it fails in both Debug and Release builds, so I guess it's not just a strange optimization...).
-
As I said, the string is empty. A previous function, which is used to set the directory variable, checks whether the directory exists or not and empties the string otherwise. Again, I excluded all possible problem sources - it is just not "that easy". I still believe that it is a compiler bug (and it fails in both Debug and Release builds, so I guess it's not just a strange optimization...).
lpCurrentDirectory [in] Pointer to a null-terminated string that specifies the current drive and directory for the new process. The string must be a full path that includes a drive letter. If this parameter is NULL, the new process will have the same current drive and directory as the calling process. (This feature is provided primarily for shells that need to start an application and specify its initial drive and working directory.) An empty string would be wrong for this parameter, as you've said yourself. I'd be tempted to do something like:
LPCTSTR szDir = strDir.GetLength () ? strDir : NULL;
and use szDir in your CreateProcess call - that'll make it easier for your debugging to verify what you're passing to the function. If the directory really exists, try using filemon from www.sysinternals.com to see what checks windows does on the directory. Maybe is has to not only exist, but have some permissions set? Maybe it has to be readable by the current user? Iain.
Plz sir... CPallini CPallini abuz drugz, plz plz help urgent.
-
lpCurrentDirectory [in] Pointer to a null-terminated string that specifies the current drive and directory for the new process. The string must be a full path that includes a drive letter. If this parameter is NULL, the new process will have the same current drive and directory as the calling process. (This feature is provided primarily for shells that need to start an application and specify its initial drive and working directory.) An empty string would be wrong for this parameter, as you've said yourself. I'd be tempted to do something like:
LPCTSTR szDir = strDir.GetLength () ? strDir : NULL;
and use szDir in your CreateProcess call - that'll make it easier for your debugging to verify what you're passing to the function. If the directory really exists, try using filemon from www.sysinternals.com to see what checks windows does on the directory. Maybe is has to not only exist, but have some permissions set? Maybe it has to be readable by the current user? Iain.
Plz sir... CPallini CPallini abuz drugz, plz plz help urgent.
I am not talking about an existing directory - the directory string is just empty (and I checked that a million times). In fact, even if I never touch the variable holding the directory it still fails for some reason.
(strCurDir.IsEmpty() ? NULL : strCurDir)
This is the part that fails. Even if IsEmpty() returns true, it still passes something invalid (an empty string as I assume). And I used your workaround already, and yes, it worked. I am not really looking for a solution, I just want to know why that simple statement fails, even if it is correct. But I guess it's really a compiler bug... can't explain otherwise.