You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
String constants currently aren't very useful as they do not have null terminators, and they are normal Rust UTF-8 strings. This means that users have to do runtime conversions in order to pass these strings to winapi functions, instead of just grabbing a raw pointer and tossing it in.
A solution needs to be found using a (procedural?) macro that will transform a string literal into a constant with methods to access both the UTF-8 and UTF-16 variants, both with and without a null terminator.
The text was updated successfully, but these errors were encountered:
I've implemented two ways, one using a decl macro + old proc_macro_derive for UTF16, and another using proc_macro_attribute for everything. I prefer the first one. L-like expression level macro for UTF16 literals may also be implemented if needed, I use it in my local projects. No external dependencies except for the separate crate for procedural macros. Target Rust is probably 1.31 (rust-lang/rust#53555 (comment))
Everything is here https://github.com/MSxDOS/string_const
Besides having a lot of implicit dependencies, wstr uses encode_utf16 for everything and forces dynamic linking to std for some weird reason. Stable is also irrelevant here as either would require a version bump from 1.6 for procedural macros to work.
I don't know if it has all the features we need.
It obviously doesn't as it's just a simple expression level macro.
String constants currently aren't very useful as they do not have null terminators, and they are normal Rust UTF-8 strings. This means that users have to do runtime conversions in order to pass these strings to
winapi
functions, instead of just grabbing a raw pointer and tossing it in.A solution needs to be found using a (procedural?) macro that will transform a string literal into a constant with methods to access both the UTF-8 and UTF-16 variants, both with and without a null terminator.
The text was updated successfully, but these errors were encountered: