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=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,fe66ebb10f69d726
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.68.227.166 with SMTP id sb6mr618632pbc.4.1331082275145;
        Tue, 06 Mar 2012 17:04:35 -0800 (PST)
MIME-Version: 1.0
Path: 
 h9ni47808pbe.0!nntp.google.com!news2.google.com!volia.net!news2.volia.net!feed-A.news.volia.net!news.ecp.fr!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Convert wide_string to string (as the same byte array)
Date: Tue, 6 Mar 2012 19:04:30 -0600
Organization: Jacob Sparre Andersen Research & Innovation
Message-ID: <jj6c71$v37$1@munin.nbi.dk>
References: 
 <f88cc8ca-183a-40c7-a01c-2adc1137d845@b18g2000vbz.googlegroups.com>
 <jj3r0r$653$1@munin.nbi.dk>
 <5368448.8.1331049289886.JavaMail.geo-discussion-forums@pbbpr1>
NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net
X-Trace: munin.nbi.dk 1331082274 31847 69.95.181.76 (7 Mar 2012 01:04:34 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Wed, 7 Mar 2012 01:04:34 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Date: 2012-03-06T19:04:30-06:00
List-Id: <comp.lang.ada>

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:5368448.8.1331049289886.JavaMail.geo-discussion-forums@pbbpr1...
> On Monday, March 5, 2012 5:58:48 PM UTC-8, Randy Brukardt wrote:
>>
>> An alternative to Adam's solution would be to use the Ada2012 encoding
>> functions (A.4.11), specifically Ada.Strings.UTF_Encoding.Wide_Strings, 
>> and
>> use a UTF-8 encoding. That would be shorter, but not fixed length, so
>> whether that would work for you depends on the API you are feeding these
>> into.
>
> This may seem like a dumb question, but does that preserve order?

My understanding was that UTF-8 was designed so that ordinary byte 
comparison operations would work "properly" on UTF-8 strings (presuming no 
"overlong encodings" are used; there is no point in such things, it's like 
including NOPs in your generated instructions). That's surely true if only 
equality is involved; I believe it is also true for ordering, but as I've 
never tried it I don't want to say for absolutely certain.

                                            Randy.