check for overflow on 32bit relocations#1175
Conversation
fd5c87c to
a0e6d07
Compare
|
Don't mind the additional .gitignore changes and .c files and test.sh. @davidlattimore what test attributes should I add/remove? The test unexpectedly passes when run via cargo. I didn't see any docs about making new tests. However when compiling the same files (minus the _start shenanigan) using test.sh (assumes PWD is project root and wild is compiled) -- everything works as expected, so the linker reports the error. |
|
|
||
| #[must_use] | ||
| pub const fn from_byte_number(n_bytes: usize) -> Self { | ||
| if n_bytes == 0 || n_bytes > 8 { |
There was a problem hiding this comment.
This > could be a >= right? i.e. if we've got an 8 byte relocation, we don't need a check.
There was a problem hiding this comment.
The end result should be the same, but I realized more glaring issue -- this code assumes each relocation is a signed integer. The match should also return whether it should be signed or unsigned.
There was a problem hiding this comment.
Does it matter? I'm not sure it does. We do our computation using u64s with wrapping_add, wrapping_sub etc, so it's possible that it might work fine as-is anyway. I'm not 100% sure that it doesn't matter, but perhaps see if you can come up with a concrete example where it breaks?
There was a problem hiding this comment.
Hm okay I think you're right. I was thinking about 32 bit signed vs unsigned relocations, but I don't even see the distinction in the match. This function was computing wrong values though because my silly mistake with shift op precedence, which I fixed and also added tests for.
a0e6d07 to
e4608b8
Compare
|
CI on tumbleweed seems to be failing because of formatting -- maybe it has different version of the tool? |
|
I created #1183 to help debug such weird cases in CI. |
|
I temporarily added commit to check clang version to test if the version in CI is the same. EDIT: the version on tumbleweed is |
a4dfcf5 to
e15bbe3
Compare
e15bbe3 to
ab9702d
Compare
Fixes #1149