Re: Characters with codes >= 128

[sommar@enea.UUCP (Erland Sommarskog)]

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