Khyber Sen

The variable-length `data` field is also mistranslated. It should be `[libc::c_int]` in Rust, not a zero-sized array, `[libc::c_int; 0]`. Moreover, we can't derive `Copy` and `Clone` for dynamically sized types...

This bug is due to `c2rust transpile` mistranslating `&a[i]`. This should be purely an `a.offset(i)` without any `*` derefs (which cause UB on the out-of-bounds deref) or `&`/`&mut` refs. That...

We should update this to use the `core::ffi::c_*` types now that they're in `core`, so we don't have to worry about not being able to use the `std::os::raw` types in...

Yeah, I agree. A `--ctypes-prefix` option is much more flexible, and in the future once things are stabilized, we can default to `core::ffi`.

`core::ffi::c_*` was just stabilized in 1.64: https://github.com/rust-lang/rust/issues/94501#issuecomment-1186301451.

I believe `clang` reads the `compile_commands.json` itself, separately from `c2rust-transpile`, and `clang` should take into account the `command`/`arguments` fields and all of their include directories. So I'm not sure what...

Is there a reason we need to test `strexb` specifically? Are we testing memory accesses to inline asm operands in general, or just testing memory access to inline asm operands...

Should we also hook the [`Allocator`](https://doc.rust-lang.org/std/alloc/trait.Allocator.html) methods for when code gets partially refactored into safe, idiomatic Rust?

Or if `Allocator` is `System` and is using `libc::{malloc, realloc, free, memalign}`, would we still hook those with our current implementation? Or can we not hook anything inside `libstd` as...

If we could preserve `clang` attributes (https://github.com/immunant/c2rust/issues/342), perhaps it would be best to hook functions marked with `__attribute__(({malloc,allocator}))`.