You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@oli-obk actually it is an integer in the first place, however the upstream library (winapi) cast the integer to a raw pointer (maybe for convenience using it together with the raw Windows APIs) when it defined that variable (see above comment). So i can't use the original integer value in constant evaluation context now :(
I can work around this by (re-)defining those integers myself again. (Arguably the winapi crate can change its definitions to avoid this.) I'm not seeking for any changes, just want to record this use case.
I can offer you a stable workaround, but it's very unsafe and if you screw up by placing a real pointer in an integer constant we will error, and if we don't, we might so in the future. If you do undefined behaviour at compile-time, it means the behaviour (compilation success) is also undefined.
Activity
crlf0710 commentedon Sep 15, 2018
Just encountered this, when i try to define a constant that uses
::winapi::um::winuser::IDC_ARROW
as an integer, which is defined as:pub const IDC_ARROW: LPCWSTR = 32512 as LPCWSTR;
oli-obk commentedon Oct 1, 2018
@crlf0710 what is your use case for casting a raw pointer to an integer? Is there any reason you can't use
*const ()
or something similar?crlf0710 commentedon Oct 2, 2018
@oli-obk actually it is an integer in the first place, however the upstream library (
winapi
) cast the integer to a raw pointer (maybe for convenience using it together with the raw Windows APIs) when it defined that variable (see above comment). So i can't use the original integer value in constant evaluation context now :(I can work around this by (re-)defining those integers myself again. (Arguably the
winapi
crate can change its definitions to avoid this.) I'm not seeking for any changes, just want to record this use case.oli-obk commentedon Oct 2, 2018
I can offer you a stable workaround, but it's very unsafe and if you screw up by placing a real pointer in an integer constant we will error, and if we don't, we might so in the future. If you do undefined behaviour at compile-time, it means the behaviour (compilation success) is also undefined.
crlf0710 commentedon Oct 2, 2018
@oli-obk Great to know, thanks a lot!
const fn
#57563if
andmatch
in constants" #49146MSxDOS commentedon Jul 15, 2019
I'm confused, what's wrong with putting a real pointer in an integer constant?
Btw, the following code compiles just fine:
43 remaining items