Date: Mon, 18 Sep 95 10:26:58 -0700 From: Bakul Shah <bakul@netcom.com> To: Poul-Henning Kamp <phk@critter.tfs.com> Cc: Terry Lambert <terry@lambert.org>, hackers@freefall.freebsd.org Subject: Re: Policy on printf format specifiers? Message-ID: <199509181727.KAA09594@netcom10.netcom.com> In-Reply-To: Your message of "Mon, 18 Sep 95 05:31:58 PDT." <6585.811427518@critter.tfs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> As far as I recall there is still some concern about Sanskrit and 10646 > isn't there ? Last I looked Unicode handled Sanskrit and other Indian languages fine. [Indian languages support is dear to my heart so I looked into it back when Unicode-1 was being worked on -- AFAIK there have been no changes in this area since then] Presumably Terry wants Unicode support in the kernel so that one can print kernel messages in any language. While I agree with his sentiment IMHO we have a long way to go before that becomes critical. We need a filesystem that'll support Unicode file names, common applications need support for Unicode input/output etc. Hmm.... Support for reading/writing of Unicode filenames may be required in the kernel. How else can you deal with code like sprintf(name, "%s.core", p->p_comm); where p_comm points to a Unicode filename? Bruce writes: > I think wchar_t's were made 32 bits so that they are the same as rune_t's. > I don't know if this is important. I too think 16 bit is good enough. 10646 is a 32 bit standard but given that other than Unicode no other pages are populated and that Unicode supports all living and many (most?) dead languages and that except for scholars of dead languages (a tiny tiny percentage of people) no one else will benefit *even if* pages beyond Unicode are ever used, allowing for such extension now is IMHO a waste of space. rune_t can be made 16 bit, too. > How are you supposed to print such strings in ANSI C? If and when true wchar_t support becomes a reality, one presumes fonts for at least the local language and English will be supported. Window systems, with their bazillion fonts should have no problem :-). Printf support for wchar_t (and wchar_t *) should really be specified by the standards people. If they haven't, may be they should be petitioned. --bakul
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509181727.KAA09594>