add implementations of memcpy et al #128
Conversation
behind the "mem" Cargo feature, which used to be named "weak" fixes rust-lang#126
|
@bors: r+ |
|
📌 Commit a1caa7c has been approved by |
add implementations of memcpy et al behind the "mem" Cargo feature, which used to be named "weak" fixes #126 Possible solution to #126 r? @alexcrichton
| } | ||
|
|
||
| #[no_mangle] | ||
| pub unsafe extern "C" fn memset(s: *mut u8, c: i32, n: usize) -> *mut u8 { |
There was a problem hiding this comment.
Why c is i32? Will it work on all architectures? maybe it should be isize or usize?
There was a problem hiding this comment.
It should be c_int but it's better not to depend on libc, which is where c_int is defined. Right now, c_int is defined as type c_int = i32 in libc.
Will it work on all architectures?
That's a good question. AVR seems to define int as 16-bit. I don't know about MSP430. You probably know that better. It's likely that all these implementations don't work correctly on architectures where sizeof(usize) is neither 32 or 64.
There was a problem hiding this comment.
Yes, on MSP430 int is 16bit. And I would like to have a working memset on MSP430. My point is that if you make it isize instead of i32 it will be compatible with all architectures that rust supports AFAIK.
There was a problem hiding this comment.
But 64-bit architectures expect c to be i32 (c_int is 32-bit on 64 and 32 bit architectures).
There was a problem hiding this comment.
Both x86_64 and AArch64 do not care if you pass a 64bit or 32bit value inside their 64bit registers. And the receiving code does cast to i8 anyway.
|
☀️ Test successful - status-appveyor, status-travis |
Add some tests for pow
behind the "mem" Cargo feature, which used to be named "weak"
fixes #126
Possible solution to #126
r? @alexcrichton