home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / std_unix / volume.28 / text0101.txt < prev   
Encoding:
Text File  |  1992-08-17  |  2.7 KB  |  56 lines

  1. Submitted-by: thorinn@diku.dk (Lars Henrik Mathiesen)
  2.  
  3. gwyn@smoke.brl.mil (Doug Gwyn) writes:
  4. >The promoters of Unicode were informed of the (numerous) problems in
  5. >fitting Unicode into the existing practice, reflected in Standard C
  6. >multibyte character support, [...]
  7.  
  8. Why is it so bad that Unicode is not like earlier ``extended
  9. encodings''? Existing code is a large problem, of course, but what is
  10. the problem relative to Standard C itself? The standard provides both
  11. wide and multibyte characters, and Unicode happens to fit the former
  12. definition instead of the latter.
  13.  
  14.   1) Of course it would be nice to be able to use the good old library
  15.   calls with the fancy new character set. So, if your text encoding fits
  16.   into EUC or whatever, it will work as Standard C multibyte characters,
  17.   but what does that mean? As far as I can see, you cannot use strcat,
  18.   index, or printf("%s") on a multibyte string anyway, you need extra
  19.   magic to make sure that shift states match properly.
  20.  
  21.   2) For the programmer, it seems easier to just use wchar_t strings;
  22.   the usual string-handling idioms ("while (*cp++)") carry over with
  23.   just a change of declarations, and it is possible to implement direct
  24.   equivalents of every string-oriented function in the library.
  25.  
  26.   (When multibyte characters are used, some of the idioms will work, but
  27.   everything that tries to interpret the characters, even just to find a
  28.   '/', will have to use mbtowc/mbstowcs or a non-standard routine. If
  29.   you have to convert to wchar_t anyway, what's the point?)
  30.  
  31.   3) There is a problem in that the standard defines wide character
  32.   constants and wide string literals in terms of multibyte characters.
  33.  
  34.   However, Unicode does define a ``data interchange'' format (UTF), for
  35.   transmission through channels that like to mung control characters.
  36.   This format happens to be usable as a Standard C multibyte encoding as
  37.   well --- it maps the source character set to itself, uses NUL only to
  38.   code NUL, and has no shift state as such; after editing C source in a
  39.   Unicode editor, you can save it ``as UTF'' and the result will be
  40.   nicely acceptable to an 8-bit C compiler with the right default
  41.   locale. And when you upgrade to a Unicode C compiler, you can convert
  42.   your source again.
  43.  
  44. If the problem is that POSIX wants to insist on a subset of Standard
  45. C, or C bindings for some system functionality, that cannot work with
  46. Unicode; then I have very little sympathy: The direction that Unicode
  47. was taking must have been clear well before anything within POSIX was
  48. finalized, and disregarding it may well turn out to have been, let's
  49. say, infelicitous.
  50.  
  51. Lars Mathiesen (U of Copenhagen CS Dep) <thorinn@diku.dk> (Humour NOT marked)
  52.  
  53.  
  54. Volume-Number: Volume 28, Number 103
  55.  
  56.