3 ms·
That doesn't bother me per-se - those all caps names are pretty much all directly from the standard C bindings, and it makes sense to preserve that naming for t
by AndrewGaspar 2y ago
That doesn't bother me per-se - those all caps names are pretty much all directly from the standard C bindings, and it makes sense to preserve that naming for the sake of having that 1:1 mapping with the ground truth C definition.
The actual issue here is that this "simple driver in Rust" is having to touch those direct C bindings at all - if Microsoft is going to advertise that they have support for writing drivers in Rust, that should presumably mean an API surface that's native to the language.
- queuebert 2y agoI see your point, but it makes it hard for Rust programmers to grok the code, as all caps denotes a constant. Even enums are camel case.
- haileys 2y agoThis is pretty normal for Rust code that FFIs to external libraries. There's a lot more complexity in writing FFI code - you have to think very carefully about everything you do. Case convention is a triviality here.
- dwattttt 2y agoI believe Rust has added the ability to mark FFI functions as safe to call at their definition site (https://blog.rust-lang.org/2024/10/17/Rust-1.82.0.html#safe-items-with-unsafe-extern https://blog.rust-lang.org/2024/10/17/Rust-1.82.0.html#safe-...) That way functions can be marked as accurate/"ok" to call in safe code by the author of the bindings. They could absolutely not be safe; in that case, the binding author is in error marking it so.
- taurknaut 2y ago> that should presumably mean an API surface that's native to the language. It reads pretty naturally to me as referring to the implementation of the driver.