I hate Win32 (Was: The new std.process is ready for review)
Lars T. Kyllingstad
public at kyllingen.net
Sun Mar 31 14:16:56 PDT 2013
On Sunday, 31 March 2013 at 20:08:05 UTC, Vladimir Panteleev
wrote:
> On Sunday, 31 March 2013 at 15:21:38 UTC, Lars T. Kyllingstad
> wrote:
>> As you may already have guessed, it does *not* print
>> "TerminateProcess failed" and exit with code 0.
>>
>> But does it print "TerminateProcess succeeded" and exit with
>> code 1? NO! It prints NOTHING and exits with code 123, because
>> TerminateProcess() terminates the CURRENT process when it is
>> passed INVALID_HANDLE_VALUE. Aaaaargh!
>
> How did INVALID_HANDLE_VALUE get so far in the code as to reach
> TerminateProcess? Shouldn't an enforce call have been in place
> to validate whatever the source of the handle is?
I was operating under the (reasonable, IMO) assumption that
TerminateProcess would fail if given an invalid handle, and that
such a check would therefore be redundant. This certainly seems
to be the case on newer Windows versions.
As it turns out, INVALID_HANDLE_VALUE is *not* an invalid handle
value, and consequently the function does not fail.
> Anyway, this is documented behavior. You can pass
> GetCurrentProcess() to TerminateProcess to terminate the
> current process.
This is not specified in the TerminateProcess() documentation,
which simply says that hProcess must be "a handle to the process
to be terminated". (It is mentioned in a user comment, though.)
http://msdn.microsoft.com/en-us/library/windows/desktop/ms686714%28v=vs.85%29.aspx
You're right that it *is* specified in the GetCurrentProcess()
documentation, but there is no explicit warning that this
particular magic value coincides with another magic value.
> Your plight was caused by the unfortunate (or perhaps,
> unforesighted) coincidence that GetCurrentProcess() returns the
> special (magic) value of (HANDLE)-1, the same value of
> INVALID_HANDLE_VALUE.
...which is just incredibly poor design.
Lars
More information about the Digitalmars-d
mailing list