-
Notifications
You must be signed in to change notification settings - Fork 977
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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
|
|
||
internal static class BooleanExtensions | ||
{ | ||
public static bool IsTrue(this BOOLEAN b) => b != BOOLEAN.FALSE; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See also please #1978 (comment)
Proposed Changes
Microsoft Reviewers: Open in CodeFlow