home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / std / internat / 623 < prev    next >
Encoding:
Internet Message Format  |  1992-08-15  |  4.8 KB
  1. Xref: sparky comp.std.internat:623 comp.std.c:2475
  2. Path: sparky!uunet!know!hri.com!snorkelwacker.mit.edu!ai-lab!wheat-chex!glenn
  3. From: glenn@wheat-chex.ai.mit.edu (Glenn A. Adams)
  4. Newsgroups: comp.std.internat,comp.std.c
  5. Subject: Re: Handling ISO 10646 UCS in C
  6. Message-ID: <26631@life.ai.mit.edu>
  7. Date: 15 Aug 92 18:50:26 GMT
  8. References: <Bt1792.48L@immd4.informatik.uni-erlangen.de>
  9. Sender: news@ai.mit.edu
  10. Followup-To: comp.std.internat
  11. Organization: MIT Artificial Intelligence Laboratory
  12. Lines: 88
  13.  
  14.  
  15.   From: mskuhn@immd4.informatik.uni-erlangen.de (Markus Kuhn)
  16.   Date: 15 Aug 92 15:34:13 GMT
  17.  
  18.   Are there any proposals about future extensions to Standard C that will
  19.   allow the programmer to use ISO 10646/Unicode strings as easily as
  20.   char []?
  21.  
  22. No.  Feel free to make a proposal to your local standards organization.
  23.  
  24.   Will wchar_t be fixed to UCS-2 or will the standard commitees introduce two 
  25.   new char types e.g.
  26.  
  27.      ucs2_t     for the 16-bit ISO 10646 BMP (also known as Unicode)
  28.      ucs4_t     for the full 32-bit ISO 10646 code
  29.  
  30.   together with new string constant notations for both of them and a lot
  31.   of new library functions for arrays of these new types? (I'd prefer 
  32.   introducing two new types a lot!)
  33.  
  34. At least one vendor (Microsoft) is using wchar_t to refer to the 16-bit
  35. UCS2 form (they have as much as said they will not support UCS4).  Using
  36. wchar_t does make certain things easier in terms of integrating the
  37. existing wchar string functions already part of standard C implementations.
  38.  
  39. A number of others, including myself, have been using new type definitions
  40. similar to the one you propose above.
  41.  
  42. Efforts are underway in the Unicode Implementation Subcommittee to
  43. undertake defining a basic set of functions for processing Unicode
  44. data (10646 UCS2).  I personally expect to see a lot of different
  45. proposals being made over the next few years as to new extensions
  46. for string and text processing of 10646 data.  If you have concrete
  47. proposals to make, I'm sure the Unicode subcommittee would like to
  48. hear about them.
  49.  
  50. To my knowledge, there are *no* commercial available systems which
  51. support the entirety of Unicode in its full glory, let alone having
  52. a standard API for dealing with this data.
  53.  
  54. A useful analogy might be that of the rise of TCP/IP networking.  The
  55. standard was first available around 1981 or thereabouts; however, it
  56. took until the 4.2BSD UNIX release from Berkeley in 1984 before it
  57. started catching on; and that was because Sun Microsystems adopted it
  58. and began selling systems everywhere.  Even today we don't have a 
  59. single API for doing networking, especially when you look across
  60. different OSs.  I expect that the tools needed for processing Unicode
  61. and 10646 data will take some time in their development; and more
  62. time still until a standard might emerge.  It would be a serious mistake
  63. to try to create a standard at this time ex nihilo.
  64.  
  65.   Will C programs be allowed to be UCS-2 files in addition to ASCII files
  66.   which would make entering Unicode characters in string constants and
  67.   comments as easy as ASCII characters today?
  68.  
  69. Compiler developers should seriously consider using 10646 UCS-2 for source
  70. file representations.  Beyond simply string constants and comments, one
  71. should also allow symbols, keywords, and syntactic tokens to use UCS-2.
  72. However, changes will be necessary for preprocessors and lexical scanners
  73. due to (1) the much larger tables potentially needed for a 65,536 element
  74. character set (UCS-2); and (2) the ability in 10646 to encode a text
  75. element (e.g., A WITH ACUTE) in multiple ways (e.g., A WITH ACUTE or
  76. A + NON-SPACING ACUTE).  [If a keyword or symbol permits this text
  77. element to be part of it, then the lexical scanner must provide
  78. equivalence classes made of strings of character code elements in order
  79. to recognize these multiple encodings of the same information as being
  80. equivalent.  This is a bit like having lower case and upper case not
  81. be distinguished in symbols; in this case, the different ways to spell
  82. out the same symbol should not constitute differences for lexical
  83. recognition.]
  84.  
  85.   What will be the new equivalent of \0? \x0000 or \ffff or another special
  86.   character?
  87.  
  88. Since both 10646 UCS-2 and UCS-4 incorporate ASCII encodings identically,
  89. the NULL character is encoded at 0x0000 and 0x00000000 for UCS2 and UCS4,
  90. respectively.
  91.  
  92. The character encoding 0xFFFF (in UCS-2) is reserved and explicitly not
  93. assigned a character value.  Therefore, it can be used as a special
  94. marker for software; e.g., it can be coerced to a signed integer to
  95. yield a value of -1 (at least on 2s complement machines).  Thus, the
  96. standard C library usage of -1 to signify EOF can easily be maintained.
  97. [Note that the encoding 0x00FF *is* a character; namely, the last
  98. character of ISO8859-1 which was directly re-encoded in Unicode,
  99. i.e., LATIN SMALL LETTER Y DIAERESIS.]
  100.  
  101. Glenn Adams
  102.