Incorrect integer casts for some Windows APIs #31841
Comments
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Feb 24, 2016
Similar to rust-lang#31825 where the read/write limits were capped for files, this implements similar limits when reading/writing networking types. On Unix this shouldn't affect anything because the write size is already a `usize`, but on Windows this will cap the read/write amounts to `i32::max_value`. cc rust-lang#31841
This was referenced Feb 24, 2016
bors
added a commit
that referenced
this issue
Feb 26, 2016
Similar to #31825 where the read/write limits were capped for files, this implements similar limits when reading/writing networking types. On Unix this shouldn't affect anything because the write size is already a `usize`, but on Windows this will cap the read/write amounts to `i32::max_value`. cc #31841
bors
added a commit
that referenced
this issue
Feb 26, 2016
CryptGenRandom takes a DWORD (u32) for the length so it only supports writing u32::MAX bytes at a time. Casting the length from a usize caused truncation meaning the whole buffer was not always filled. cc #31841 This is the same as rust-random/rand#99. I think it's a good idea to keep the implementations in sync. r? @alexcrichton
|
Well I didn't find any more so I'll close this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In a few places in
stdthere are casts fromusizetou32ori32for Windows APIs which causes breakage on 64-bit.Some examples I have found so far:
There may be more.
The text was updated successfully, but these errors were encountered: