Prepares HRESULT to transparently store NTSTATUS values #989
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Introducing idiomatic Rust error handling for
NTSTATUS
values requires two steps:HRESULT
to transparently encodeNTSTATUS
values.NTSTATUS
struct.This PR proposes a solution to solving the first (for the moment). The core idea revolves around the fact that any
NTSTATUS
value can be mapped to anHRESULT
value, that is distinct from any otherHRESULT
value. This makesHRESULT
the perfect container to store any Win32 system error code,NTSTATUS
, or (regular)HRESULT
.The following changes were done:
HRESULT::from_ntstatus()
:This turns
NTSTATUS
values intoHRESULT
s, similar tofrom_win32()
. Outside of testing, this is not used, but rather is in preparation of a futureimpl From<NTSTATUS> for windows::Result
.HRESULT::ntstatus_code()
:Similar to
win32_code()
verifies whether the stored value is anNTSTATUS
value and, if so, returns the decodedNTSTATUS
value.HRESULT::message()
:Since
FormatMessage
can only be used with (regular)HRESULT
s, this function produces a generic message forNTSTATUS
values (e.g."NTSTATUS: 0xC0000005"
).std::fmt::Debug for Error
did not need adjustments. In case of anNTSTATUS
, themessage
already contains the decoded value and an additional debug field is not required.If that all looks reasonable, I would try working on the second part. For that I would need a bit of guidance, though (e.g. would this be best done in
gen_replacement()
orgen_extensions()
, and so on).