Re: Interpretation of extensions different from Unix/Linux?

[Adam Beneschan <adam@irvine.com>]

On Aug 17, 3:28 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:

> The problem here is that String really is not the right type, but since you
> can't have string literals for private types in Ada, you can't make it a
> private type. (And if you could have string literals, it still couldn't be
> used with the existing I/O packages, it would be way too incompatible.)

That wouldn't even be an issue if UTF-8 were strictly a "storage
format" as you called it above.  If that were the case, you wouldn't
need string literals for it.  I think the problem is that UTF-8 is
something of a hybrid.  If all characters in the string are in the
32..126 range, the "sequence of octets" stored in the UTF-8 string is
identical to the graphic characters stored in a String.  (UTF-8 was
designed purposefully so that would happen.)  In cases like that, it
makes sense to use a string literal.

I can understand how "hybrid" types like that can cause headaches for
fans of strong typing.  A "String" should be an array of graphic or
control characters; an encoded type should be a sequence of octets;
but here we need a type that is sometimes one thing and sometimes
another.  So I can respect the decision to make these String types,
but I don't like it.

Also, I'm afraid that using String can backfire.  If I understand it
correctly, the decision was that the Name parameter of Text_IO.Open
should be interpreted as a UTF-8 octet sequence even though it's a
String.  But the intent is to allow string literals.  At some point,
though, some poor innocent programmer in Germany or Spain is going to
try to use a string literal (or a Latin-1 string variable) with an
umlaut or an accented vowel in it and get totally screwed up since
those characters don't represent themselves in UTF-8 encoding, and
they'll end up puzzling over how their program created a file with a
Chinese character in the middle of the name.  (Yeah, I know, that's
very unlikely; most likely the UTF-8 encoding will simply be invalid.)

                                              -- Adam