我正在尝试编写名为insert
的方法的rustdoc测试。
在测试的最后一行中调用了测试功能,当我将其注释掉时,测试通过就可以了。
错误消息:
$ cargo test
Compiling reproduce v0.1.0
(file:///home/user/reproduce)
Finished dev [unoptimized + debuginfo] target(s) in 2.03s
Running target/debug/deps/reproduce-17ad4bb50aa9c47e
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
Doc-tests reproduce
running 1 test
test src/lib.rs - MyStruct::method (line 19) ... FAILED
failures:
failures:
src/lib.rs - MyStruct::method (line 19)
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out
error: test failed, to rerun pass '--doc'
代码:
impl MyStruct {
pub fn new(lsb: u8, step: usize) -> MyStruct {
let mask: u8 = match lsb {
1 => 0b0000_0001,
2 => 0b0000_0011,
_ => 0b0000_1111
};
MyStruct { lsb, mask, step }
}
/// # Examples
/// ```
/// extern crate reproduce;
/// extern crate rgb;
///
/// use std::slice;
/// use rgb::RGB;
///
/// let msg = "This is a secret message".as_bytes();
/// let img = vec![RGB {r: 0, g: 0, b: 0}; 800*500];
///
/// // Create a reference to the bytes of img
/// let p: *const Vec<RGB<u8>> = &img;
/// let p: *const u8 = p as *const u8;
/// let p: &[u8] = unsafe {
/// slice::from_raw_parts(p, 3*800*500)
/// };
///
/// let settings = reproduce::MyStruct::new(2, 12);
/// let new_data = settings.method(p, &msg);
/// ```
pub fn method(&self, img: &[u8], msg: &[u8]) -> Vec<u8> {
let mut ret = img.to_vec();
let mut n = 0;
for ch in msg.iter() {
for i in 1..=8/self.lsb {
let shift = (self.lsb*i) as u32;
ret[n] = (ret[n] & !self.mask) |
(ch & self.mask.rotate_right(shift)).rotate_left(shift);
n += self.step;
}
}
ret
}
}
是否有通过rustdoc测试的特殊规则(例如,使用assert!
宏来证明它返回了正确的值)?
我之所以问是因为我的方法通过了非常相似的代码的集成测试,所以我很确信这是正确的
答案 0 :(得分:2)
这与在rustdoc测试中运行无关。您的代码显示未定义的行为,因为它是不正确的。在测试的外部中运行相同的代码也让我感到恐慌。
您正在假设内存的布局方式-这些假设绝不会得到任何编译器保证的支持。一种获取指针的“正确”方法是:
let p = img.as_ptr() as *const u8;
但是,尽管这消除了关于Vec
布局方式的假设,但其余代码仍然是{em> still 并假设RGB
的布局。这项更改使它停止了对我的恐慌,但是我不确定它是否可以正确运行,并且我不知道它是否会在其他计算机上崩溃,或者在下一次Rust更新后在我的计算机上崩溃
我问是因为我的方法通过了非常相似的代码的集成测试,所以我很确定它是正确的
这恰恰是未定义行为的危险,这就是为什么unsafe
仅应在经过良好测试的代码中使用,而且还应在容易理解假设和保证的地方使用它。