Post by Bill Cunningham[snip]
Post by Antoninus Twinkglibc represents wide characters using their Unicode (ISO-10646)
code point, but other platforms don't do this. Also, the use of C99
universal character names of the form \unnnn does not solve this
problem. Therefore, in internationalized programs, the format string
should consist of ASCII wide characters only, or should be
constructed at run time in an internationalized way (e.g., using
gettext(3) or iconv(3), followed by mbstowcs(3)).
I have gettext and FSF's libiconv on my system. I will have to find out
what mbstowcs is. Ok I see what you're trying to say. Basically stay away
from C's wchar.h functions and use something better.
That can't be what he is saying because mbstowcs is, roughly speaking,
one of "C's whcar.h functions".
I think, from the sort of programs I've seen you write, you will be
fine with standard C for a while yet.
There *is* a problem with wide character support but it is not fixed
by using other libraries. If there is going to be a miss-match
between the wide character representation used by your compiler and
that used by your run-time, then your will have trouble. The solution
is to use only run-time strings (this is what the quote is saying but
I have translated it from the system specific language of glibc,
gettext etc.). This applies to any program using any such facilities,
including the standard ones[1].
If you can assume that there is no such miss-match, then all is well.
[1] In fact it applies to all programs that use any character data, it
is just that we all assume that the execution and source character
sets are the same these days. In the old days, this problem occurred
even with printf("Hello world.\n");
--
Ben.