On 10/15/12 8:27 AM, Marijn Haverbeke wrote:
Extremely common. I'm somewhat appalled that the blanket 'all C functions are unsafe' idea is even being considered (and enthusiastically supported). Yes, C code can segfault and do other nasty things if you call it incorrectly. But wrapping every call to a C function in an unsafe block will dilute the 'red flag' role of unsafe blocks to the point of making them just painful noise, and wrapping the C functions themselves in a wrapper function to make them safe is, in most cases, a wax nose -- the wrapper will not be able to guarantee that the call won't go wrong, so no safety is added.
Usually, one needs such a wrapper anyway to sanitize the arguments. Essentially any C function that takes a pointer (which is most of them) needs a wrapper to be invoked safely. This wrapper needs to ensure that the data pointed at is of the right size and type, is not null in some cases, etc.
Additionally, an awful lot of C libraries create their own reference counting systems (examples: Cairo, Azure, any "Core" library on Mac OS, all Objective-C libraries, GTK+, all GObject-based libraries, all COM-based libraries on Windows). All of the objects passed to these functions must be wrapped, to ensure that the reference counting is right. Failure to get the reference counting right leads to exploitable security vulnerabilities (use-after-free + indirect function call + heap-spray). Rust can enforce that the reference counting is used properly, but only if the raw functions are off-limits.
Certainly, some C functions don't need wrappers. I'd be OK with a #[safe] annotation for stuff like libmath. For those functions, writing a wrapper is pure boilerplate, and reducing the boilerplate to 7 characters seems fine.
Patrick _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
