From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!attcan!uunet!mcvax!enea!sommar From: sommar@enea.se (Erland Sommarskog) Newsgroups: comp.lang.ada Subject: Re: 8-Bit characters for Ada Message-ID: <4097@enea.se> Date: 20 Nov 88 21:33:06 GMT Organization: ENEA DATA AB, Sweden List-Id: David Kinder (kinder@biin.com) writes: >AI-420 (submitted over 3 years ago) brought up the issue of an an 8-bit >character type. This should be a hot issue with non-US Ada customers who >should reasonably insist on support for their (non-English) characters in >STRING variables and in TEXT_IO. I've seen packages that define a new >extended character type, however this character type can't be used with >TEXT_IO, so a whole new (and non-standard) I/O package must be used. I recall I brought up this problem in this newsgroup a little more than a year ago. The conclusion if you wanted to use eight-bit characters was to define a new type with a new Text_IO or to simply cheat. (You are not really required to write an entirely new Text_IO you can map to the old, but you still have problems with being non-standard.) The big problem with Ada is that it defines only characters 32-126 as printable. It also says that a user that in/outputs non-prinable charcaters cannot rely on that Text_IO works as described. I generally very hesitant to proposals to change the Ada standard. One point with Ada was that it should be complete. But a minor change like extending Ada to support the ISO/Latin standards (8859/1-9) has my full support. I even see it as necessary. At minimum 8859/1 should be supported. I don't know about AI-420. Could you, or anyone else, give more info? -- Erland Sommarskog ENEA Data, Stockholm sommar@enea.se "Frequently, unexpected errors are entirely unpredictable" - Digital Equipment