I hate Win32 (Was: The new std.process is ready for review)

[Lars T. Kyllingstad]

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