-
Notifications
You must be signed in to change notification settings - Fork 127
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
0xFFFFFFFF00000000 parsed as 32 bit #74
Comments
So, the current behaviour is pretty straightforward, if perhaps not entirely obvious: All integer expressions (including literals) are evaluated assuming 64-bit unsigned, wrapping, arithmetic. The final result is then truncated to the size of the element it's going into. That's usually 32 bits but can be 8, 16 or 64 bits when using the I'm not really clear on what behaviour you're suggesting instead, but the alternative options I can think of involve some severe practical drawbacks:
|
For me an approach like the following would be less unexpected:
This would mean for 32 bits Some random fun with the current arithmetic:
|
Treating literals differently from other arithmetic also seems oddly inconsistent.
That's what we do now.
Until I read this I misunderstood your first suggestion above. This really highlights the inconsistency to me.
When I tried this, I realized I was mistaken in my previous comment. I'd forgotten that when we truncate down to the cell size, we give an error if the truncated bits are anything other than all 0s or all 1s. I guess that's a tradeoff - we want to allow both all 0s and all 1s to allow for both signed and unsigned values (both common cases). Not allowing anything else is an attempt to catch if we're truncating important information. In the second two examples here the top bits are 0xfffffffe, hence the errors. I am now wondering if simply truncating without errors might be a better idea, given the confusion it's caused you, |
Yes, exactly what I see and wondered about. I call this the "all 0s or all 1s" rule now.
Yes, this would be another good solution. My expectations were that there are good reasons not to truncate at cell size but throw an error, so I did not want to propose this. Perhaps we could always truncate but throw an out-of-bounds warning if necessary. (One can argue and I am undecided if negative values are out-of-bounds. I agree, negative values are valid use cases, but still they are no valid unsigned ints) At least always truncating would better match to my expectations. So some options:
I am totally fine with 1. but I'd be in favor to 4. as it keeps current use cases valid without warnings, leaves the option to spot possible errors and seems a bit more consistent to me. |
Sorry I've taken so long to reply again. I think your option (4) is a good one, at least in the short term. Basically we keep the same logic, but demote the error to a warning. I just pushed a change which should implement this. |
Perhaps I am missing something, but uint64_t in the following range 0xFFFFFFFF00000000-0xFFFFFFFFFFFFFFFF are treated as uint32_t for property array data.
Example:
The
dtc -O dts
output of this snippet is:My expectation would be, that all uint64_t values above 0xFFFFFFFF are illegal 32bit data values. This of course includes the 64 bit values with all ones in the upper 32 bits. At least 0xFFFFFFFEFFFFFFFF is invalid.
Is there a rationale behind this or is it a bug?
We can then have a "full" 32 bit signed integer, with the sign bit being all upper 32 bits set or unset? ;-)
The text was updated successfully, but these errors were encountered: