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=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.unit0.net!news.uni-stuttgart.de!news.enyo.de!.POSTED!not-for-mail
From: Florian Weimer <fw@deneb.enyo.de>
Newsgroups: comp.lang.ada
Subject: Re: Exclusive file access
Date: Mon, 31 Aug 2015 23:12:28 +0200
Message-ID: <87zj179n7n.fsf@mid.deneb.enyo.de>
References: <eec18573-876b-4151-b13a-15a103bba30e@googlegroups.com>
	<75714e3f-c047-413d-9aa5-3ff423167863@googlegroups.com>
	<nrnswuq80yyi$.uf01xt8a4dz5.dlg@40tude.net>
	<1440837116.20971.33.camel@obry.net>
	<lnt8n39l9dme$.1lq59r9ar72t1$.dlg@40tude.net>
	<87oahpovpn.fsf@mid.deneb.enyo.de>
	<mvil865iebyb$.1of2shk5faacq$.dlg@40tude.net>
	<87y4gsmut1.fsf@mid.deneb.enyo.de>
	<p4xiiq77lt19$.1ba1le2pivgsg.dlg@40tude.net>
Mime-Version: 1.0
Content-Type: text/plain
X-Trace: news.enyo.de 1441055548 14395 192.168.18.20 (31 Aug 2015 21:12:28
 GMT)
X-Complaints-To: news@enyo.de
Cancel-Lock: sha1:JtM++80cB71geRZ/aSA2Hqnpq6o=
Xref: news.eternal-september.org comp.lang.ada:27653
Date: 2015-08-31T23:12:28+02:00
List-Id: <comp.lang.ada>

* Dmitry A. Kazakov:

>>> Semantically no. Wide_String according to RM 3.5.2 (3/3) represents a
>>> narrower set of Unicode than UTF-16.
>> 
>> I don't have a current Windows system to try this, but I think Windows
>> allows you to use lone surrogates in file names.  Such names are not
>> valid UTF-16, but valid UCS-2.
>
> The system may have integrated AI that accepts names in English: "a file
> with the name of Swahili dhadi". Would it make ASCII same as Unicode?

Sorry, there is no need for being silly.  Non-encodable file names are
definite problems and happen in practice (see Java programs on
non-Windows platforms in a multi-byte locale).  The user may select a
file, but the application cannot open it.  That's a poor user
experience.  Or backup software could skip some files because it
cannot seem them, leading to data loss.

>>>> Wide_Wide_String definitely is not.
>>>
>>> Definitely is. Both are to represent arrays of same sets of Unicode
>>> characters. The representation of Wide_Wide_String is of course irrelevant
>>> when used to specify an external file name, right?
>> 
>> You can end up with non-expressible names, depending on how the
>> conversion to the external representation is performed.  (I.e., the
>> system may have file names which cannot be encoded as
>> Wide_Wide_String.)
>
> Wasn't the purpose of Unicode to represent all possible characters?

This discussion isn't about characters, it's about conversions for
sequences of code units which do not quite match the (current) Unicode
specifications.