> > Whether each "symbol" of UTF-8 string takes one
> > or more bytes - it doesn't matter for C compiler.
>
> Oh yea? Ever tried to get the count of chars of an UTF-8 string at compile
> time? :-P

Fortunately didn't :)

> The size of char[] and wchar_t[] can be deduced at compile time. UTF-8 is a
> more "dynamic" data type and doesn't fit the low level stuff. Actually, I
> think there should have been developed a reference C library implementation
> before even releasing this data type since it's incompatible with just about
> everything.
>
> > The type of UTF8 string is char[] for C compiler
>
> Speaking of compilers, now you're wrong. You can *never* express an UTF-8
> string in a char[], you need an unsigned char[], that is inherently
> incompatible with a C/C++ string literal.

I doubt that C++ spec guarantees such problems - it seems it declares this
aspect as implemenation-dependant. At least I didn't have problems using chars
with value > 128 in arrays declared as char[] and never had problems with them
with any compilers I had. So it's safe for UTF8 too. May be just compiler's
authors are smart.

> > since it doesn't care about what's stored in that array.
>
> Well, the compiler doesn't care, of course not. I was speaking from a
> conceptually POV. I care, and I'd imagine that all maintainers-to-be also
> cares. It just happened to coincide with the fact that the compiler *can't*
> implicitly (without emitting diagnostic(s)) convert a C++ string literal
> into an "unsigned char*".

Yes, I agree with this. But most compilers are rather smart to allow
disabling particular warnings, so it doesn't hurt that much.

> But since I now respond to this issue, I might add that I think libxml2 is
> more correct in typedefing XML_Char to unsigned char, making it inherently
> incompatible with a C/C++ string literal.
>
> But back to the issue that started this thread. Why do we even use functions
> that only allow XML_Char* as input when we mostly give them C++ string
> literals (which are const char[])? Not only is all this casting bad, ugly,
> wrong and code-bloat. It's conceptually wrong.

May be we should provide an overloaded wrappers that will just cast their
args to XML_Char* and call original functions?