Either you change the C++ lib to not behave unsafely for inputs.
Or you manually change the binding to keep the invariant.
The assumption behind linking to C++ code is that it doesn't contain unsoundness. If it does the library was fucked way before.
But this discussion is about a tool that:
* does not change the C++ code to behave correctly for all inputs
* does not (and technically cannot) generate safe Rust bindings that keep the invariant (the bindings are automatically generated under the assumption that all C++ code is safe for all inputs).
I think this is already invalidated by countless code generation and build scripts.
Even regular safe Rust assumes you use unsafe in a proper manner.
This build tool assumes your C++ code is safe enough to wrap around unsafe trivially.
This build tool, as first proposed, knowingly exposed macros that can cause memory unsafety with the wrong inputs, without making you write unsafe. If a build tool makes assumptions like "you probably know what you're doing with that C++ code" without asking you to write unsafe, it is just as wrong as an implementation of unchecked indexing that wasn't marked unsafe (because "you'll probably know not to use this unless you're really in bounds."). It is clear that you consider this a trivial matter, but many people very heavily involved in the Rust community (including the people working on its soundness proofs) do not.
This was done to deal with remarks Chromium devs had against Rust C++ binding.
In lieu of that it's liberal treatment of unsafe is understandable.
I have a hard time believing those Chromium devs know what they want.
Their request allows safe Rust to introduce undefined behavior, making the unsafe Rust keyword meaningless (since now you can't even grep for the places in the code where this UB is introduced), and eliminating the actual reason they want to use Rust in the first place (to avoid undefined behavior, segfaults, CVEs, etc.).
The only thing complying with the request will achieve is hurt the language. Once the chromium devs start hitting the same CVEs and segfaults in Rust that they were hitting in C++, they will just tell the whole world that Rust is as bad as C++ and using it is not worth it.
Rust std wasn't yet verified to not contain unsafe behavior. In fact, some modelling discovered and fixed unsafe behavior in Rust std libs.
Same happens here. If you discover that for inputs you have unsafe behavior calling ffi, you uncapsulate it in way that prevents misuses or fix in source ffi lib.