Any chance of adding the rationale to the code?
I'm really short of time right now, so you need to find somebody else to make such a change.
I am willing to believe that requests for a wchar_t (or utf-8 or System Locale charset) representation are common enough to justify caching the data after the first request.
That's not the issue; the real issue is memory management.
But then why throw it away in the first place? Wouldn't programs that create unicode from wchar_t data also be the most likely to request wchar_t data back?
Perhaps. But are they likely to access the string they just created again at all? They know what's in it, so why look at it again?
In all other cases, (wstr_length == length), and wstr can be generated by widening the data without having to inspect it. Is it worth eliminating wstr_length (or even wstr) in those cases, or is that too much complexity?
It's too little saving.
What I'm asking is that (1) The other values be documented as reserved, rather than as illegal.
How is that different?
(2) The macros produce an error rather than silently corrupting data.
In debug mode, or release mode? -1 on release mode. Regards, Martin