From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu From: "Douglas A. Gwyn" Message-ID: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit References: , <16d2f27efa70d6b1ca98ab72d6c91245@mightycheese.com> Subject: Re: [9fans] ... in the Kingdom of Sources Date: Tue, 9 Sep 2003 08:34:03 +0000 Topicbox-Message-UUID: 2ff24b7c-eacc-11e9-9e20-41e7f4b1d025 rob pike, esq. wrote: > there are two important differences. first is that (old) ANSI C > did not provide any formatted i/o for wchar_t, rendering them > essentially useless. The target clientele at the time insisted that they did not want us to specify more than the minimum necessary support, and that they would happily invoke the multibyte<->wide conversions when necessary. I remember Plauger relaying that promise. Not surprisingly, as soon as they got the capability they started pushing for the missing functions, which became part of a normative amendment to the C standard by 1995 (along with mode on the stream to control whether automatic conversion is or is not applied). > the way plan 9 handles encoding errors with runetochar > and chartorune, by introducing the 'error rune' 0x80, is vastly > more convenient and effective than the error return values set > by mbtowchar stuff. Since an encoding error should "never" occur, we thought it better to stop scanning rather that plow ahead and convert some unknown amount of garbage once synchronization has been lost. It was also not evident that there would always be a "spare" wide-character code available for in-band signaling. I think the main difference driving the designs is that the Standard C version has to accommodate a huge variety of multibyte and internal encoding systems, whereas Plan 9 could just pick one. Anyway, the C wide-character facilities are quite similar to the legacy char-based ones, so Boyd shouldn't be finding them "confusing".