![]() Perhaps hex literals could therefore truly be converted to unsigned types, assuming that PowerShell's type-conversion magic prevents any ill follow-on effects. If hex literals are treated the same as decimal literals - always resulting in signed types - the range 0x8000000000000000 to 0xffffffffffffffff becomes unavailable, given that widening to probably makes no sense for values that are presumed to be bit fields. Perhaps v6 is an opportunity to fix this problem, a change that probably falls into Bucket 3: Unlikely Grey Area. Unlike with decimal literals, is the largest type supported in this case. That is, whenever the bit pattern happens to have the high bit set in the resulting data type, a negative number results. With hexadecimal literals, the value is unexpectedly treated like a bit pattern: the always signed target type is chosen based on whether it can accommodate all bits, even if the resulting number is negative. If you use an expression with the same value, the type instantly widens to rather than : (2147483648).GetType().Name yields Int64, as expected: the smallest signed type that can accommodate the value. On a side note, I found the following discrepancy surprising ( 2147483648 is ::MaxValue + 1):.With decimal literals, the expectation is honored: the type is chosen so that the value fits as a positive number into an - always signed - integer type, and the type chosen goes even beyond, up to and, ultimately. While the approaches differ - Rust sticks with int, but warns if the result would be a negative number - what these languages have in common is that they honor the fundamental user expectation that a literal specified without a sign result in a positive number.īy contrast, PowerShell's current behavior depends on whether the literal is in hex or decimal format (base-10 representation, not the data type): Like C++, C# also chooses int / Int64 or uint / UInt64 based on the value of a literal. ![]() I don't see this repro-ing anymore, so I guess it was fixed. There used to be another bug, where switch($b) wouldn't match if $b was or - only when $b was. You may argue that this is by some sort of design - but you cannot argue that this is very error prone. To give another example where powershell gets in the way with its obsession with : ![]() I don't know about Rust, but in C/C++ when I say UINT64 c = 0xffffffff the result is 0x00000000ffffffff and not 0xffffffffffffffff, or an exception thrown. If I wanted signed I would have said $b = -1. When I say $b = 0xffffffff it's pretty clear to me that I mean to use. Except, as you say, powershell does things under the covers, like converting to, whether I like it or not, and outside of my control. I'm not sure how this addresses my problem. Error: "Value was either too large or too small for a UInt64." Expected behavior Error: "Value was either too large or too small for a UInt32."Ĭannot convert value "-1" to type "System.UInt64". ![]() The bug seems to be that PS doesn't realize that is has to upcast 0xffffffff to int64 and not to int32, as it won't fit.Ĭannot convert value "-1" to type "System.UInt32". It seems like it always tries to dumb down every number to, and does it poorly. Description: I can't make powershell use correctly types like or. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |