The data type PRUnichar is not defined by NSPR. Therefore, it should not use the PR prefix. PRUnichar is now defined in mozilla/base/src/nscore.h as follows: /** ucs2 datatype for 2 byte unicode characters */ typedef PRUint16 PRUcs2; /** ucs4 datatype for 4 byte unicode characters */ typedef PRUint32 PRUcs4; #ifdef NS_UCS4 typedef PRUcs4 PRUnichar; #else typedef PRUcs2 PRUnichar; #endif I suggest that the data types be renamed as follows: PRUcs2 ==> nsUcs2 PRUcs4 ==> nsUcs4 PRUnichar ==> nsUnichar Many people have asked whether the definition of PRUnichar should be moved to NSPR. I argue that, because NSPR does not use PRUnichar nor has any functions that operate on PRUnichar, it is risky to put the definition of PRUnichar in NSPR. We may screw up the definition of PRUnichar without realizing it.

reassigning to dp, since component is XPCOM

I am not owner of base. Last I knew, kipp owned it.

If you really want it changed, feel free to fix all the source.

You can mark the bug resolved-wontfix. That's fine by me. I can't resolve this bug because I don't own mozilla/base/src/nscore.h.

I suggest the bug remain open. If in a future release of NSPR these data types collide with those in NSPR, the cost of fixing the problem could be much higher.

How about somebody gets brave and runs this: for FILE in `find . \( -name \*.cpp -o -name \*.h \) -print` do sed 's/PRUnichar/nsUnichar/g' $FILE > x mv x $FILE done

Waterson is a brave hacker, I think. If he doesn't do it, I'll do it (but I might use perl rather than sed). /be

This ought to be reassigned to a brave hacker. Waterson, if you're overloaded, try dp; like I said, I'll take it if you guys won't (I think dp gets in line ahead of me now that base is folded into xpcom). /be

PRUnichar forever!