`c_bool` is not (always?) `c_int`, causes miscompilation of extent hook API

[Arnavion]

https://github.com/tikv/jemallocator/blob/fd00e12cc531d15a52e1ace32ff33eb3366bc5e4/jemalloc-sys/src/lib.rs#L53

This leads to a miscompilation when using API that involves c_bool, ie the extent hook API. For example, when my implementation of this Rust typedef wrote to the supposed c_bool pointers, it ended up smashing other variables in the caller's stack. I'm using the x86_64-unknown-linux-musl and x86_64-unknown-linux-gnu targets with gcc 11, gcc 12 and gcc 13.

jemalloc expects to be using C99 bool via the stdbool.h header, and the equivalent of that is Rust's bool, not c_int. jemalloc does have this header for Windows MSVC that defines it to win32's BOOL which is apparently an int. I'm not sure if even that is required, since web search seems to indicate MSVC also got stdbool.h in VS 2013, but I don't have Windows to check myself.

---

Workaround: Write the extent hook implementations with the correct signature (using Rust bool), then transmute then into the incorrect signatures that tikv-jemalloc-sys requires (using c_int) via std::mem::transmute.

[BusyJay]

How about defining c_bool conditionally? If it's on MSVC windows, pick c_int, otherwise pick bool.

[Arnavion]

Did you confirm that building on MSVC does indeed use the compat header and not whatever stdbool.h MSVC (apparently) aleady ships with?

[BusyJay]

No, I don't have any machine that runs Windows. The file is named stdbool.h and get included in the header searching path by configure script, so even MSVC ships one, the former should be used instead.

[Arnavion]

Okay. Then yes, the fix would be:

#[cfg(target_env = "msvc")]
type c_bool = c_int;
#[cfg(not(target_env = "msvc"))]
type c_bool = bool;

[BusyJay]

Cool, can you send it as a PR?

[Arnavion]

54