Ah, good point. Yeah, in my mind, there was a thin wrapper library to allocate that buffer and such. Guess, we can't have that for the actual exposed interface.
I was also thinking, having to pass the size of the buffer and the buffer pointer separately, is just another C-ism, but that does make sense here then, too, because it's not implicitly relying on the memory layout of some List/Vec/whatever type.
Similarly, ETWGetEvents can only return a number of events, because it can't return a List/Vec/whatever.
Interesting perspective. And kind of weird to now be on-board with this API design, while also thinking I'm not touching that without a wrapper.
Maybe in a few decades, the Rust ABI will have stabilized and become ubiquitous enough, that we can have at least some of these amenities. But chances are, Rust will look quite antique by then, too, and we're back to writing wrappers anyways. 🙃
Ah, good point. Yeah, in my mind, there was a thin wrapper library to allocate that buffer and such. Guess, we can't have that for the actual exposed interface.
I was also thinking, having to pass the size of the buffer and the buffer pointer separately, is just another C-ism, but that does make sense here then, too, because it's not implicitly relying on the memory layout of some List/Vec/whatever type.
Similarly,
ETWGetEventscan only return a number of events, because it can't return a List/Vec/whatever.Interesting perspective. And kind of weird to now be on-board with this API design, while also thinking I'm not touching that without a wrapper.
Maybe in a few decades, the Rust ABI will have stabilized and become ubiquitous enough, that we can have at least some of these amenities. But chances are, Rust will look quite antique by then, too, and we're back to writing wrappers anyways. 🙃