Cleanup PowerStatus interop #2041
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2041 +/- ##
===================================================
+ Coverage 27.70556% 28.07081% +0.36525%
===================================================
Files 879 880 +1
Lines 266701 266672 -29
Branches 37945 37945
===================================================
+ Hits 73891 74857 +966
+ Misses 187585 186586 -999
- Partials 5225 5229 +4
|
RussKie
added
code cleanup
ghost
removed
the
📭 waiting-author-feedback
|
|
||
| internal static class BooleanExtensions | ||
| { | ||
| public static bool IsTrue(this BOOLEAN b) => b != BOOLEAN.FALSE; |
There was a problem hiding this comment.
It may be more prudent to override the operators !, !=, and == for comparisons to both BOOLEAN and bools
Also, maybe I am mistaken, but isn't there already a BOOL which is identical to this? Is there no way to make both BOOLEAN and BOOL extend some common type which extends byte and then add these helper functions to that underlying type? Just trying to avoid duplicating code
There was a problem hiding this comment.
You can't unless you make it a struct instead of an enum. It can be done per my example, it just isn't something the Core architects liked as it isn't technically "correct" and enums can potentially get better optimizations. It does work, however, and makes usage pretty easy, imho.
There was a problem hiding this comment.
isn't there already a BOOL which is identical to this?
@zsd4yr no, BOOL and BOOLEAN are different sizes in the headers (which was the reason BOOLEAN is added here)
make it a struct instead of an enum [...] It does work, however
@JeremyKuhne only due to bug-for-bug compatibility with Desktop Framework, structs can trigger different behavior in calling conventions than primitives, passing them as a stack pointer instead of by-value in a register. Initially .NET Core caused crashes in WPF when using HRESULT struct wrappers as return values, they restored the bug from Desktop to keep this particular scenario compatible but I'm not entirely sure it will work in other situations, considering that the calling conventions can make differences between wrapper structs and wrapped values, so they are a bit of a minefield.
relevant discussions: [1] [2] [3]
Technical TLDR: the native calling conventions for returning structs in
SomeStruct(__stdcall SomeInterface::*SomeMethod)();andSomeStruct(__stdcall *SomeMethod)(SomeInterface*);
(i.e. passing this explicitely or implicitely) are not identical and .NET cannot differentiate between them, historically it has been mixed up due to a bug, and today (for compatibility) it has to guess looking at the struct which one is more likely what you meant, if it happens to chose the wrong case for your usage of the struct you crash or get garbage results.
There was a problem hiding this comment.
See also please #1978 (comment)
RussKie
added
the
📭 waiting-author-feedback
Proposed Changes
Microsoft Reviewers: Open in CodeFlow