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.7 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!mcvax!enea!sommar From: sommar@enea.UUCP (Erland Sommarskog) Newsgroups: comp.lang.ada Subject: Re: Characters with codes >= 128 Message-ID: <2272@enea.UUCP> Date: Sat, 12-Sep-87 10:47:01 EDT Article-I.D.: enea.2272 Posted: Sat Sep 12 10:47:01 1987 Date-Received: Tue, 15-Sep-87 01:48:47 EDT References: <8709100440.AA04224@rand-unix.rand.org> Reply-To: sommar@enea.UUCP(Erland Sommarskog) Followup-To: comp.lang.ada Organization: ENEA DATA Svenska AB, Sweden List-Id: hermix!colbert@rand-unix.ARPA writes: >In response to my answer to his question about character types >sommar@seismo.css.gov (Erland Sommarskog) writes: >>I think Martin Moore's solution was much more simple and elegant. It will >>work on any Ada system that doesn't check character assignments for >>Constraint_error. >Unfortunately, Martin Moore's solution is NOT portable either. It only works >because: Well, I didn't say it was portable, did I? I would say it is "presumably" portable. > 1) Unchecked_Conversion is implemented in DEC Ada. As far I understand, the LRM doesn't mention Unchecked_character as optional. It's true, however, that it allows for arbitrary restrictions. > 2) The size of type Character objects in DEC is 8 bits. A quite reasonable assumption with the architectutres of today. And the only time, you're in trouble is when the size is exactly seven bits. > 3) DEC did not give a Constraint_Error on the assignemt (which may > be a bug in DEC's implementation). Verdix Ada on VAX/Unix doesn't seem bother, either. It's probably a violation of the langauge definition, but somehow it seems like a frequent violation. (Check your Ada system. Have it read a non-ASCII character and mingle around with it. Do you get Constraint_error?) > 4) DEC does not "place restrictions on unchecked conversions" > (13.10.2 P2); True, as I said under 1), but other hand what reasons for restrictions are there in this case? > 5) DEC truncates high order bits if the source value if its size is > greater than the size of the target type (this is really only a > problem with the specific example given by Moore, in that he used > the type Integer as the source type as opposed to an 8 bit type). Yes, replace Integer with Very_short_integer and it's fixed. >The principle benefit of my proposed solution is the creation of a portable >abstraction that represents the problem. Re-implementing a Text I/O for this >type is a small price to pay for this benefit (especially when Moore's >technique can be used in the implementation of this Text I/O - Sufficiently >issolated to prevent major impact on the system that I'm implementing and later >porting [as pointed out by another reader of this group]). >to this message. Mr. Colbert seems to share my opinion about "presumably" portable. Else he wouldn't propose Moore's technique in Text_io_8_bit. Now, we don't have to rewrite Text_io_8_bit until we meet Ada system does not implement things as we need them. It's perfectly true, that if we stick to Moore's original idea, we have a lot more code to rewrite. If I were to write a 10000-lines system I would surely consider Text_io_8_bit. Presently, I'm not. Just want to write some small pieces of code to demonstrate more a meaningful character comparisons than the use of a simple collating sequence. (Those who read comp.std.internat know what I'm talking about.) And, guys, can't we agree on that it would have been much easier if the language definition in one way or another had given place for a wider character concept than 128 ASCII codes? -- Erland Sommarskog ENEA Data, Stockholm sommar@enea.UUCP