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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,5bcc293dc5642650 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Received: by 10.68.21.229 with SMTP id y5mr373454pbe.1.1318895387438; Mon, 17 Oct 2011 16:49:47 -0700 (PDT) Path: d5ni24122pbc.0!nntp.google.com!news1.google.com!postnews.google.com!u10g2000prl.googlegroups.com!not-for-mail From: ytomino Newsgroups: comp.lang.ada Subject: Re: Why no Ada.Wide_Directories? Date: Mon, 17 Oct 2011 16:47:49 -0700 (PDT) Organization: http://groups.google.com Message-ID: <7156122c-b63f-487e-ad1b-0edcc6694a7a@u10g2000prl.googlegroups.com> References: <9937871.172.1318575525468.JavaMail.geo-discussion-forums@prib32> <418b8140-fafb-442f-b91c-e22cc47f8adb@y22g2000pri.googlegroups.com> NNTP-Posting-Host: 118.6.135.155 Mime-Version: 1.0 X-Trace: posting.google.com 1318895386 575 127.0.0.1 (17 Oct 2011 23:49:46 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 17 Oct 2011 23:49:46 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: u10g2000prl.googlegroups.com; posting-host=118.6.135.155; posting-account=Mi71UQoAAACnFhXo1NVxPlurinchtkIj User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-Header-Order: HNKUARELSC X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_5_8) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.202 Safari/535.1,gzip(gfe) Xref: news1.google.com comp.lang.ada:18530 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2011-10-17T16:47:49-07:00 List-Id: On Oct 18, 6:33=A0am, "Randy Brukardt" wrote: > > Say what? > > Ada.Strings.Encoding (new in Ada 2012) uses a subtype of String to store > UTF-8 encoded strings. As such, I'd find it pretty surprising if doing so > was "a violation of the standard". > > The intent has always been that Open, Ada.Directories, etc. take UTF-8 > strings as an option. Presumably the implementation would use a Form to > specify that the file names in UTF-8 form rather than Latin-1. (I wasn't > able to find a reference for this in a quick search, but I know it has be= en > talked about on several occasions.) > > One of the primary reasons that Ada.Strings.Encoding uses a subtype of > String rather than a separate type is so that it can be passed to Open an= d > the like. > > It's probably true that we should standardize on the Form needed to use > UTF-8 strings in these contexts, or at least come up with Implementation > Advice on that point. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0Randy. Good news. Thanks for letting know. My worry is decreased a little. However, even if that is right, Form parameters are missing for many subprograms. Probably, All subprograms in Ada.Directories, Ada.Directories.Hierarchical_File_Names, Ada.Command_Line, Ada.Environment_Variables and other subprograms having Name parameter or returning a file name should have Form parameter. (For example, I do Open (X, Form =3D> "UTF-8"). Which does Name (X) returns UTF-8 or Latin-1?) Moreover, in the future, we will always use I/O subprograms as UTF-8 mode if what you say is realized. But other libraries in the standard are explicitly defined as Latin-1. It's certain that Ada.Character.Handling.To_Upper breaks UTF-8. So we can not use almost subprograms in Ada.Characters and Ada.Strings for handling file names. (For example, Ada.Directories.Name_Case_Equivalence returns Case_Insensitive. We can not use Ada.Strings.Equal_Case_Insensitive to compare two file names.) It means standard libraries are separated UTF-8 from Latin-1. It's not reasonable. I wish it be solved.