================
Comment at: source/Host/windows/PipeWindows.cpp:100-101
@@ -98,2 +99,4 @@
Error error;
- do {
+ ::UUID unique_id;
+ ::RPC_CSTR unique_string;
+ if (SUCCEEDED(::UuidCreate(&unique_id)) &&
----------------
zturner wrote:
> Don't use global scope identifiers before typenames unless it's necessary to
> disambiguate. The same rule doesn't apply to functions though,
> ::GlobalFunction() is ok.
It is necessary to disambiguate for UUID. I've removed it from RPC_CSTR.
================
Comment at: source/Host/windows/PipeWindows.cpp:102-103
@@ +101,4 @@
+ ::RPC_CSTR unique_string;
+ if (SUCCEEDED(::UuidCreate(&unique_id)) &&
+ SUCCEEDED(::UuidToStringA(&unique_id, &unique_string)))
+ {
----------------
zturner wrote:
> Is it correct to use SUCCEEDED() / FAILED() with RPC calls? They dont'
> return HRESULTs. Seems like the return values are just standard windows
> error codes.
Whoops. I thought RPC_STATUS was an SCODE, which is the same as an HRESULT.
I've fixed the code to check for multiple possible successful results.
================
Comment at: source/Host/windows/PipeWindows.cpp:115
@@ +114,3 @@
+ // creation could have failed.
+ error.SetError(ERROR_NOT_ENOUGH_MEMORY, eErrorTypeWin32);
+ }
----------------
zturner wrote:
> I would just set the error to the return code of whichever call failed.
> Normally we use GetLastError() here, but The RPC functions seem to return the
> error value directly.
Done.
When I thought it was an HRESULT, there was no obvious way to map an HRESULT
back to a Win32 error. Now I see that RPC_STATUSes are Win32 errors, so I'm
returning the status directly.
http://reviews.llvm.org/D7509
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
_______________________________________________
lldb-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
