Unnecessary *mut constraint in LPCTSTR

[cr0sh]

MSDN documentation of WNDCLASSEXW,
states the field lpszClassName has type LPCTSTR which is a pointer to constant string.

However, the generated bindings on WNDCLASSEXW defines the field as *mut 16, which seems overly constrained for constant (t-)strings.

Current workaround is just casting *const pointers into *mut, but it could be more simple to define them as *const pointers.

[kennykerr]

Yes, this is something we can improve. The struct field in this case includes a "const" attribute in metadata so we just need to ensure that this translates into a *const rather than *mut field.

[kennykerr]

This is now a little better thanks to the introduction of the PWSTR and PSTR types. Here's an example:

https://github.com/microsoft/windows-rs/blob/master/examples/create_window/src/main.rs

Beyond that, I'd like to introduce const functions or macros that can produce a PWSTR/PSTR from a literal. That's tracked by #581.

[agausmann]

PWSTR and PSTR still just wrap *mut u8 and *mut u16 respectively. The example you have there has the expression PSTR(b"window\0".as_ptr() as _), which, after type inference, is PSTR(b"window\0".as_ptr() as *mut u8). It's still converting *const u8 to *mut u8, still UB.

[kennykerr]

Agreed its not yet ideal or safe, but why is it UB? The memory is not actually modified.

[agausmann]

I was mistaken, it's not directly UB, I believe I was thinking of transmute<&T, &mut T> which is not the same at all. But it can definitely be unsound if the interface asks for *mut u8 and you're casting a *const u8.

The struct field in this case includes a "const" attribute in metadata so we just need to ensure that this translates into a *const rather than *mut field.

If they're considered to be const pointers on the other side of the FFI boundary, I guess it's okay.

[kennykerr]

These are now const thanks to #1468