Steven Edwards wrote:

Hi Rob,

On 9/24/05, Robert Shearman <[EMAIL PROTECTED]> 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.

--
Rob Shearman



Reply via email to