SHLWAPI: implement PathIsValidChar{A,W}

[Juan Lang]

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