by Michael S. Kaplan, published on 2006/01/25 15:46 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/01/25/517586.aspx
I can think of one crucial scenario where the right behavior is not always what is conventionally considered the smart behavior by reasonable people.
That scenario is appcompat/backcompat.
The code may be doing something that is completely wrong and weird, but someone may be relying on it. So we keep in the wrong behavior.
This of course happens often, which is why the title has a #1 there -- I anticipate that I'll be giving more examples in the future. :-)
So, today's example takes us into the new FindNLSString function in Vista, and its ancestors (the managed IsPrefix, IndexOf, LastIndexOf methods and particularly the IsSuffix method).
You see, somebody decided a long time ago that the empty string is the suffix of every other string. I guess it is hard to argue that the empty string is not in fact a suffix since it is not not visible....
But when you apply that to FindNLSString with the FIND_ENDSWITH flag (which returns an index), it gets weirder. In order to meet this requirement, it has to return an index value that is one greater than the last character of the string (a length defined in the cchSource parameter).
Now I suppose this is somewhat mitigated by the fact that the pcchFound parameter will indicate that the length of the string that was found was also zero. So that people who are using the function attentively will not be creating their own personal buffer overrun.
Unfortunately, there are apparently managed applications that rely on this functionality (there was a large customer app which reportedly would not boot when the behavior was changed). And IsSuffix depends on FindNLSString with the FIND_ENDSWITH flag when supporting Windows-only cultures in Whidbey running on Vista (it is the real reason why the function was added!). So even though it is not very 'smart', it is in some sense the 'right' thing to do.
But it definitely makes paying attention to that pcchFound parameter worthwhile!
This post brought to you by "e" (U+0065, a.k.a. LATIN SMALL LETTER E)
# Michael S. Kaplan on 25 Jan 2006 3:51 PM:
# Gabe on 26 Jan 2006 3:43 AM:
# Michael S. Kaplan on 26 Jan 2006 4:41 AM:
# Phylyp on 26 Jan 2006 9:32 AM: