home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / std / unix / 388 < prev    next >
Encoding:
Internet Message Format  |  1992-08-17  |  3.3 KB
  1. Path: sparky!uunet!uunet!not-for-mail
  2. From: thorinn@diku.dk (Lars Henrik Mathiesen)
  3. Newsgroups: comp.std.unix
  4. Subject: Re: POSIX update
  5. Date: 17 Aug 1992 14:42:30 -0700
  6. Organization: Department of Computer Science, U of Copenhagen
  7. Lines: 54
  8. Sender: sef@ftp.UU.NET
  9. Approved: sef@ftp.uucp (Moderator, Sean Eric Fagan)
  10. Message-ID: <16p6g6INNs4i@ftp.UU.NET>
  11. References: <15rucjINNdov@ftp.UU.NET> <166v0lINNpj8@ftp.UU.NET> <16b9drINNero@ftp.UU.NET> <16i6laINNssj@ftp.UU.NET>
  12. NNTP-Posting-Host: ftp.uu.net
  13. Keywords: posix, unicode, iso10646, microsoft windows nt
  14. X-Submissions: std-unix@uunet.uu.net
  15.  
  16. Submitted-by: thorinn@diku.dk (Lars Henrik Mathiesen)
  17.  
  18. gwyn@smoke.brl.mil (Doug Gwyn) writes:
  19. >The promoters of Unicode were informed of the (numerous) problems in
  20. >fitting Unicode into the existing practice, reflected in Standard C
  21. >multibyte character support, [...]
  22.  
  23. Why is it so bad that Unicode is not like earlier ``extended
  24. encodings''? Existing code is a large problem, of course, but what is
  25. the problem relative to Standard C itself? The standard provides both
  26. wide and multibyte characters, and Unicode happens to fit the former
  27. definition instead of the latter.
  28.  
  29.   1) Of course it would be nice to be able to use the good old library
  30.   calls with the fancy new character set. So, if your text encoding fits
  31.   into EUC or whatever, it will work as Standard C multibyte characters,
  32.   but what does that mean? As far as I can see, you cannot use strcat,
  33.   index, or printf("%s") on a multibyte string anyway, you need extra
  34.   magic to make sure that shift states match properly.
  35.  
  36.   2) For the programmer, it seems easier to just use wchar_t strings;
  37.   the usual string-handling idioms ("while (*cp++)") carry over with
  38.   just a change of declarations, and it is possible to implement direct
  39.   equivalents of every string-oriented function in the library.
  40.  
  41.   (When multibyte characters are used, some of the idioms will work, but
  42.   everything that tries to interpret the characters, even just to find a
  43.   '/', will have to use mbtowc/mbstowcs or a non-standard routine. If
  44.   you have to convert to wchar_t anyway, what's the point?)
  45.  
  46.   3) There is a problem in that the standard defines wide character
  47.   constants and wide string literals in terms of multibyte characters.
  48.  
  49.   However, Unicode does define a ``data interchange'' format (UTF), for
  50.   transmission through channels that like to mung control characters.
  51.   This format happens to be usable as a Standard C multibyte encoding as
  52.   well --- it maps the source character set to itself, uses NUL only to
  53.   code NUL, and has no shift state as such; after editing C source in a
  54.   Unicode editor, you can save it ``as UTF'' and the result will be
  55.   nicely acceptable to an 8-bit C compiler with the right default
  56.   locale. And when you upgrade to a Unicode C compiler, you can convert
  57.   your source again.
  58.  
  59. If the problem is that POSIX wants to insist on a subset of Standard
  60. C, or C bindings for some system functionality, that cannot work with
  61. Unicode; then I have very little sympathy: The direction that Unicode
  62. was taking must have been clear well before anything within POSIX was
  63. finalized, and disregarding it may well turn out to have been, let's
  64. say, infelicitous.
  65.  
  66. Lars Mathiesen (U of Copenhagen CS Dep) <thorinn@diku.dk> (Humour NOT marked)
  67.  
  68.  
  69. Volume-Number: Volume 28, Number 103
  70.