IWTSVirtualChannelManager.CreateListener expects a string of type &u8, which might be a regression

[LeonarddeR]

microsoft/windows-rs#1939 changed IWTSVirtualChannelManager.CreateListener to take a &u8 instead of a *const u8. I was able to get a const u8 by simply calling as_ptr() on a null terminated string, but obviously that does no longer work. I can prepend & and that works, but it is not ideal. &u8 would suggest a reference to a single u8 value rather than to a null terminated string.

Originally posted by @LeonarddeR in microsoft/windows-rs#1939 (comment)

[kennykerr]

I took a look at the definition in the Windows SDK and it appears this really should just be a const PSTR in metadata. I'll transfer this to the win32 metadata repo for resolution.

[kennykerr]

Let us know if there are other instances like this or whether this is just an isolated case.

[LeonarddeR]

Thanks @kennykerr

Let us know if there are other instances like this or whether this is just an isolated case.

Not insurmountable, but there seems to be a small discrepancy between IWTSVirtualChannelCallback.OnDataReceived and IWTSVirtualChannel.Write. In the write method, at least in the rust bindings, you can simply pass a &[u8] and the cbSize parameter is automatically passed to the underlying COM method based on the length of the &[u8]. On the contrary, OnDataReceived on IWTSVirtualChannelCallback_Impl takes a cbsize: u32 and pbuffer: *const u8. Yet pBuffer is annotated with In_reads(cbSize) in the metadata, therefore I'd expect the rust bindings to do the conversion to &[u8] internally. But may be I have incorrect expectations here?

[kennykerr]

If you're referring to the implementation of that interface, that's a little harder to smooth over in Rust. The SAL annotation provides the expectations for the method but doesn't enforce them so a Rust implementation may still be called with an invalid set of arguments.