Uh oh!
There was an error while loading. Please reload this page.
ARROW-7813: [Rust] Remove and fix unsafe code - #6395
Conversation
Marwes
commented
Feb 13, 2020
Removed the commits that changed the simd implemented operators. The code is definitely doing undefined behaviour though as the padding won't be initialized ( #6397 (comment) ). So either the code could do non-simd operations for the last partial block (if any). Or the padding should be initialized before reading it. |
paddyhoran
commented
Feb 13, 2020
I plan to initialize the padded region, ARROW-7836 if no-one beats me to it. |
paddyhoran
commented
Feb 13, 2020
I'll try and review this tomorrow so we can get it merged. |
Will take a look too. This needs rebase BTW. And cc @sadikovi . |
paddyhoran
commented
Feb 24, 2020
Ping @Marwes can you re-base this so we can review if you get a chance please? |
andygrove
commented
Mar 28, 2020
@Marwes Could you rebase this ? |
Rebased, CI is failing though. Not sure what to do to fix. |
paddyhoran
commented
Apr 4, 2020
This was fixed by #6800. Let me see if I can re-trigger CI. |
paddyhoran
commented
Apr 4, 2020
@kszucs how can I re-trigger CI? I tried to force-push to this branch but it has no effect. |
wesm
commented
Apr 4, 2020
Not sure what happened with GitHub (they have been having outage issues?) but I rebased and CI is running again |
nevi-me
commented
Apr 4, 2020
CI is failing with |
paddyhoran
commented
Apr 12, 2020
@Marwes looks like just some basic issues with this, want to take a quick look? I'd like to get this one merged. |
(I was "invited" to look at this PR, since I noticed some issues that needed fixing. All my comments will appear a bit random and semi-related to this PR, because of this. I will only comment on important issues.) Nice, I had named 3 things I saw in arrow 0.16.0 code (not a full review) Issue (1) about Buffer.ptr being null is being fixed here in this PR. Another common way to solve this in Rust is to use https://doc.rust-lang.org/std/ptr/struct.NonNull.html#method.dangling - an aligned non-null dummy pointer, but I won't review this solution further, Marwes can probably judge it all as well as I can. Using Issue (2) so remains, no check for allocation failure. This produces dangerous mismatches - null pointer and nonzero length - in various places. This doesn't have to be fixed in this PR, just to note that the issue is not fixed here. |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
This fix has disappeared, I can't see it in the diff anymore 😕
Might be other platforms this works on as well, but those could be added as they are found
Fixes undefined behaviour that could occur from safe code calling with `T == Box<i32>` etc.
This may cause panics in code using ByteArray or Int96 but no tests currently test these paths. Still better than the status quo which would be undefined behaviour (if the replaced code paths were hit).
Some types such as `&[Int96]` and `&[ByteArray]` can't be transmuted to a `&[u8]` as they aren't plain old data. `&mut bool` can't be transmuted to a `&mut u8` since that would allow writing values other than 0 or 1 to it.
Marwes
commented
Apr 14, 2020
That's the better solution. I just spotted the null pointer issue late in this PR and didn't want to complicate it further. Fixed the review comments. |
Thank you @Marwes for doing big work like this for better and safer code |
wesm
commented
Apr 14, 2020
Would be great to get this into 0.17.0, probably needs to be merged today cc @kszucs |
sunchao
left a comment
There was a problem hiding this comment.
+1. I only had time to skim through this but it'd be great if we have some perf numbers to show there is no regression.
kszucs
commented
Apr 15, 2020
@sunchao Included in the 0.17 release. If you find a significant regression, then we can still fix it by cutting a new release candidate. |
This removes or corrects many instances of unsafe code in the rust crates. This is by no means a complete fix and some of the fixes do not entirely fix the issues with the particular
unsafe(see comments), but in all instances it should put the code in a better place than before.Based on #6256