Steven Edwards wrote:
Hi Rob,
On 9/24/05, Robert Shearman rob@codeweavers.com wrote:
Any time a Zero-Width Non-breaking Space is specifically skipped like this it is a bug. You should *never* have to do this if you use the right functions (isspaceW, etc). Is there some other bug lurking that made this change necessary?
According to Hervé the *.inf files in the windows/system32/inf folder had some junk chars in the Unicode header or something like that and it causes the need for the skipping.
The 'junk' is a valid Unicode character that I describe above.
He was worried that isspaceW might not handle the junk properly.
#include <stdio.h> #include "wine/unicode.h"
int main(int argc, char *argv[]) { int space; space = isspaceW(0xfeff); printf("isspaceW(0xfeff) = %s\n", space ? "yes" : "no"); space = isspaceW('a'); printf("isspaceW('a') = %s\n", space ? "yes" : "no"); return 0; }
Output: isspaceW(0xfeff) = yes isspaceW('a') = no
There is a question about the sizeof WCHAR usage so I will check with him again and send along another patch later in the week.
Yes, that is another suspect change. If you send the patch again without those two changes it will be perfectly acceptable.
If Alexandre does not like the check I can also ask him to test it using isspaceW.
Sure. It is possible that the ReactOS implementation is isspaceW is broken for some reason, so I encourage Hervé to use the above simple test program to make sure it works correctly. There may also be some other bug, like not allowing whitespace between a newline separator and the start of a section header. I couldn't see a bug like this in the code, but it is possible.