Hi Hans,
Yes I contemplated that but then you reintroduce a conditional in the ascii case ( if (c > 0x7e) ), which somewhat defeats the purpose of using a lookup table.
Defeats? I don't think so. A single comparison that covers a large number of cases is different than a cascade of comparisons. Unless the compiler inlines PathIsValidCharAW, adding a comparison to PathIsValidCharA is faster than a function call anyway.
Also, that means the data type can be unsigned char, not DWORD.
I don't understand you, char class values are DWORD.
You're right, that's my mistake.
But for values of c greater than 0xff, you do not mask. This may be deliberate, I don't know, but it doesn't look correct.
It's deliberate and correct. PATH_CHAR_CLASS_OTHER_VALID *is* a mask so I do return the same value in both cases. Also remember that the return type is a BOOL so we could return TRUE everywhere but I chose to mimic Windows here and return a masked value. The tests show this is the case.
I'm still not sure it's correct. What if the call is PathIsValidCharW(0x1ff, PATH_CHAR_CLASS_LETTER) ? In this case, you return PATH_CHAR_CLASS_OTHER_VALID, which is 0x00000100. On the other hand, the call PathIsValidCharW('0', PATH_CHAR_CLASS_LETTER) returns 0.
Your test cases don't capture the entire behavior, because the caller's mask and the character class are the same. But what if they are different?
Test cases will show which is correct, of course. I've never used the function. I was just pointing out that the behavior for characters above 0xff is different than that for characters less than or equal to 0xff. Inconsistency usually means incorrectness.
--Juan
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
-
Juan Lang