If it isn't Unicode, it isn't ANY code!

by Michael S. Kaplan, published on 2007/09/23 05:51 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/09/23/5070899.aspx

Raymond makes a good point in What happens if you pass a source length greater than the actual string length? about the potential dangers of the NLS semantic for length parameters....

I make a similar point about the potential problems in Encoding APIs and Security Concerns, APIs and Security Decisions, though I stand by my point in API Consistency and Developer Comfort about how (since you cannot rely on consistency across the Win32 API, at least you can often rely on consistency within families of functions (usually).

In the end, the real errors are fourfold from the NLS point of view in the scenario Raymond talks about, in addition to the actual semantic differences with how length parameters are handled:

• You should never convert the case of file names -- preserve the case, always, as I talk about here;
• You should never pass file names to a function that uses CompareString since that is a linguistic comparisons, which the file system does not use. CompareStringOrdinal is much more appropriate as I mention here and in other posts;
• Even if the theoretical invariant_strnicmp Raymond posited were calling the right function, the fact that it assumes the two strings passed to CompareString are of the same length, which they don't have to be in that function (the simplification used in many Shell, CRT, and other functions is a dangerous over-simplification;
• Unicode is not being used!

How is the title for a new advertising slogan? :-)

This post brought to you by ओ (U+0913, a.k.a. DEVANAGARI LETTER O)

go to newer or older post, or back to index or month or day