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.szaf.org!news.enyo.de!.POSTED!not-for-mail
From: Florian Weimer <fw@deneb.enyo.de>
Newsgroups: comp.lang.ada
Subject: Re: Exclusive file access
Date: Sun, 30 Aug 2015 21:37:46 +0200
Message-ID: <87y4gsmut1.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>
Mime-Version: 1.0
Content-Type: text/plain
X-Trace: news.enyo.de 1440963466 24497 192.168.18.20 (30 Aug 2015 19:37:46
 GMT)
X-Complaints-To: news@enyo.de
Cancel-Lock: sha1:Zw1kpehTYIStkZxPAe+2UnZ+wec=
Xref: news.eternal-september.org comp.lang.ada:27643
Date: 2015-08-30T21:37:46+02:00
List-Id: <comp.lang.ada>

* Dmitry A. Kazakov:

> On Sun, 30 Aug 2015 13:35:16 +0200, Florian Weimer wrote:
>
>> * Dmitry A. Kazakov:
>> 
>>> No, I meant Wide_Wide_String.
>>>
>>> Ada's Wide_String is legally UCS-2. Windows is UTF-16. The only full
>>> Unicode string type is Wide_Wide_String. For an Indo-European language
>>> there is no difference, of course.
>> 
>> GNAT's Wide_String should be compatible with UTF-16.
>
> In the sense that Wide_String is an array of 0..2**16-1 units of the
> endianness compatible to UTF-16, yes. However the standard is silent about
> endianness and alignment (a DSP processor might deploy 32-bit units per
> unit)
>
> 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.  If GNAT supports UCS-2 for
Wide_String, it would actually improve Windows compatibility.

>> 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.)