C 结构到 Rust 的错误映射
Wrong mapping of C struct to Rust
出于教育目的,我尝试访问 Rust 中的 FILE
结构:
unsafe {
let passwd = libc::fopen("/etc/passwd".to_ptr(), &('r' as libc::c_char));
let fp = &mut *(passwd as *mut MY_FILE);
println!("flags={}, file={}", fp._flags, fp._file);
}
我通过 运行 bindgen 在 stdio.h 上获得的 MY_FILE
结构(我在 OS X 上):
bindgen /usr/include/stdio.h
不知何故,对于以写入模式打开的文件(在读取模式下为 4),_flags
总是 8
,因此此标志似乎已关闭(我使用 C
代码进行测试以验证它确实不是 4 或 8)。然而,文件指针似乎是正确的。什么会导致这个?我是从错误的头文件中提取绑定吗?我需要在 #[repr(C,)]
属性中添加什么吗?
Here 是包含结构的完整代码。
这是来自
的跟进问题
首先,您对 ToPtr
的实施会引入不合理的代码。转载于此:
// code in italics is wrong
impl ToPtr for str {
fn to_ptr(&self) -> *const i8 {
CString::new(self).unwrap().as_ptr()
}
}
这会分配一个新的 CString
和 returns 指向其内容的指针,但是当 to_ptr
returns 时 CString
被删除,所以这是悬空指针。 对该指针的任何取消引用都是未定义的行为。documentation 对此有一个很大的警告,但这仍然是一个非常常见的错误。
从字符串文字生成 *const c_char
的一种正确方法是 b"string here[=23=]".as_ptr() as *const c_char
。该字符串以 null 结尾,并且没有悬空指针,因为字符串文字在整个程序中都存在。如果你有一个要转换的非常量字符串,你 必须 在 CString
被使用时保持活动状态,如下所示:
let s = "foo";
let cs = CString::new(s).unwrap(); // don't call .as_ptr(), so the CString stays alive
unsafe { some_c_function(cs.as_ptr()); }
// CString is dropped here, after we're done with it
旁白:一位编辑 "suggested"(我是 Stack Overflow 的新手,但发表评论似乎比尝试重写我的答案更有礼貌)上面的代码可以这样写:
let s = "foo";
unsafe {
// due to temporary drop rules, the CString will be dropped at the end of the statement (the `;`)
some_c_function(CString::new(s).unwrap().as_ptr());
}
虽然这在技术上是正确的(最正确的一种),但所涉及的 "temporary drop rules" 是微妙的——之所以有效,是因为 as_ptr
引用了 CString
(实际上是一个&CStr,因为编译器把方法链改成了CString::new(s).unwrap().deref().as_ptr()) 而不是使用它,因为我们只有一个 C 函数要调用。在编写不安全代码时,我不喜欢依赖任何微妙或不明显的东西。
除此之外,我在你的代码中 fixed that unsoundness(你的调用都使用字符串文字,所以我只使用了上面的第一个策略)。我在 OSX:
上得到这个输出
0, 0, 4, 0, 0, 0, 0, 0, 0, 0, 0
0, 0, 8, 1, 0, 0, 0, 0, 0, 0, 0
0, 0, 8, 2, 0, 0, 0, 0, 0, 0, 0
0, 0, 4, 3, 0, 0, 0, 0, 0, 0, 0
那么,这符合您的结果,对吧?我还写了下面的C程序:
#include <stdio.h>
#include <unistd.h>
int main() {
struct __sFILE *fp1 = fdopen(STDIN_FILENO, "r");
struct __sFILE *fp2 = fdopen(STDOUT_FILENO, "w");
struct __sFILE *fp3 = fdopen(STDERR_FILENO, "w");
struct __sFILE *passwd = fopen("/etc/passwd", "r");
printf("%i %i %i %i\n", fp1->_flags, fp2->_flags, fp3->_flags, passwd->_flags);
}
得到输出:
4 8 8 4
这似乎证明了 Rust 的结果。 /usr/include/stdio.h
顶部有一条评论说:
/*
* The following always hold:
*
* if (_flags&(__SLBF|__SWR)) == (__SLBF|__SWR),
* _lbfsize is -_bf._size, else _lbfsize is 0
* if _flags&__SRD, _w is 0
* if _flags&__SWR, _r is 0
*/
并查找这些常量:
#define __SLBF 0x0001 /* line buffered */
#define __SRD 0x0004 /* OK to read */
#define __SWR 0x0008 /* OK to write */
这似乎与我们得到的输出相匹配:4 代表以读取模式打开的文件,8 代表写入。那么这里的问题是什么?
出于教育目的,我尝试访问 Rust 中的 FILE
结构:
unsafe {
let passwd = libc::fopen("/etc/passwd".to_ptr(), &('r' as libc::c_char));
let fp = &mut *(passwd as *mut MY_FILE);
println!("flags={}, file={}", fp._flags, fp._file);
}
我通过 运行 bindgen 在 stdio.h 上获得的 MY_FILE
结构(我在 OS X 上):
bindgen /usr/include/stdio.h
不知何故,对于以写入模式打开的文件(在读取模式下为 4),_flags
总是 8
,因此此标志似乎已关闭(我使用 C
代码进行测试以验证它确实不是 4 或 8)。然而,文件指针似乎是正确的。什么会导致这个?我是从错误的头文件中提取绑定吗?我需要在 #[repr(C,)]
属性中添加什么吗?
Here 是包含结构的完整代码。
这是来自
首先,您对 ToPtr
的实施会引入不合理的代码。转载于此:
// code in italics is wrong
impl ToPtr for str {
fn to_ptr(&self) -> *const i8 {
CString::new(self).unwrap().as_ptr()
}
}
这会分配一个新的 CString
和 returns 指向其内容的指针,但是当 to_ptr
returns 时 CString
被删除,所以这是悬空指针。 对该指针的任何取消引用都是未定义的行为。documentation 对此有一个很大的警告,但这仍然是一个非常常见的错误。
从字符串文字生成 *const c_char
的一种正确方法是 b"string here[=23=]".as_ptr() as *const c_char
。该字符串以 null 结尾,并且没有悬空指针,因为字符串文字在整个程序中都存在。如果你有一个要转换的非常量字符串,你 必须 在 CString
被使用时保持活动状态,如下所示:
let s = "foo";
let cs = CString::new(s).unwrap(); // don't call .as_ptr(), so the CString stays alive
unsafe { some_c_function(cs.as_ptr()); }
// CString is dropped here, after we're done with it
旁白:一位编辑 "suggested"(我是 Stack Overflow 的新手,但发表评论似乎比尝试重写我的答案更有礼貌)上面的代码可以这样写:
let s = "foo";
unsafe {
// due to temporary drop rules, the CString will be dropped at the end of the statement (the `;`)
some_c_function(CString::new(s).unwrap().as_ptr());
}
虽然这在技术上是正确的(最正确的一种),但所涉及的 "temporary drop rules" 是微妙的——之所以有效,是因为 as_ptr
引用了 CString
(实际上是一个&CStr,因为编译器把方法链改成了CString::new(s).unwrap().deref().as_ptr()) 而不是使用它,因为我们只有一个 C 函数要调用。在编写不安全代码时,我不喜欢依赖任何微妙或不明显的东西。
除此之外,我在你的代码中 fixed that unsoundness(你的调用都使用字符串文字,所以我只使用了上面的第一个策略)。我在 OSX:
上得到这个输出0, 0, 4, 0, 0, 0, 0, 0, 0, 0, 0
0, 0, 8, 1, 0, 0, 0, 0, 0, 0, 0
0, 0, 8, 2, 0, 0, 0, 0, 0, 0, 0
0, 0, 4, 3, 0, 0, 0, 0, 0, 0, 0
那么,这符合您的结果,对吧?我还写了下面的C程序:
#include <stdio.h>
#include <unistd.h>
int main() {
struct __sFILE *fp1 = fdopen(STDIN_FILENO, "r");
struct __sFILE *fp2 = fdopen(STDOUT_FILENO, "w");
struct __sFILE *fp3 = fdopen(STDERR_FILENO, "w");
struct __sFILE *passwd = fopen("/etc/passwd", "r");
printf("%i %i %i %i\n", fp1->_flags, fp2->_flags, fp3->_flags, passwd->_flags);
}
得到输出:
4 8 8 4
这似乎证明了 Rust 的结果。 /usr/include/stdio.h
顶部有一条评论说:
/*
* The following always hold:
*
* if (_flags&(__SLBF|__SWR)) == (__SLBF|__SWR),
* _lbfsize is -_bf._size, else _lbfsize is 0
* if _flags&__SRD, _w is 0
* if _flags&__SWR, _r is 0
*/
并查找这些常量:
#define __SLBF 0x0001 /* line buffered */
#define __SRD 0x0004 /* OK to read */
#define __SWR 0x0008 /* OK to write */
这似乎与我们得到的输出相匹配:4 代表以读取模式打开的文件,8 代表写入。那么这里的问题是什么?