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.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA 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-7-bit Received: by 10.68.27.230 with SMTP id w6mr2338159pbg.3.1318935368930; Tue, 18 Oct 2011 03:56:08 -0700 (PDT) Path: d5ni26605pbc.0!nntp.google.com!news2.google.com!news1.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Tue, 18 Oct 2011 05:56:06 -0500 Date: Tue, 18 Oct 2011 06:55:54 -0400 From: "Peter C. Chapin" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Why no Ada.Wide_Directories? References: <9937871.172.1318575525468.JavaMail.geo-discussion-forums@prib32> <418b8140-fafb-442f-b91c-e22cc47f8adb@y22g2000pri.googlegroups.com> <1gzuyf8eg0o0k.7yo8q1lqfiyr.dlg@40tude.net> <4j9sogywhu37.99zyvbiqma79.dlg@40tude.net> In-Reply-To: <4j9sogywhu37.99zyvbiqma79.dlg@40tude.net> Message-ID: <96CdnQ48jI_VxgDTRVn_vwA@giganews.com> X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-GjkFVP4Pkmr0K5xE9iP45owW8WwOGGZJwGzl6O5UKebEBbkwxYyXX+g8eEgE0IePMXRqJZz20IYhov6!B5O0FjXq4K0mbpMkF1msbd4/Rt6ZnHtpd1S4dxz9441kAVZXmb3ejMn3AEp01SY= X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 3437 Xref: news2.google.com comp.lang.ada:14038 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2011-10-18T06:55:54-04:00 List-Id: On 2011-10-17 03:59, Dmitry A. Kazakov wrote: > Wrong. All file systems share common features, which can and must be > properly abstracted. System-specific are the implementations, not the > package specifications. Not all possible file system features, even common ones, are abstracted by the standard. So the standard must pick and choose which ones to expose. > Because inability to spell the file name is not same as lacking access > rights. Access rights are external to the program code. The file name, > coded as a string literal is a part of the program. Failure of the former > is not a bug. The latter is a bug, because the file exists, is accessible > and has proper name. A program bug which cannot be fixed is a language > design bug. I don't see it the same way. Extended attributes also exist, are accessible (to the system), and have names. Yet the standard doesn't allow you to access them. Anyway it seems like this is drifting off the main topic as it sounds like the standard does have a mechanism for accessing general Unicode file names... or at least that's what I'm gathering from the discussion. The issue of character set handling is slippery business, as you know. Perhaps the fundamental problem is that Unicode text is essentially binary data. For example when reading a Unicode file one needs to treat it as a binary file and then decode the contents (into String, Wide_String or Wide_Wide_String as desired) as it is read. Personally the idea of holding on to encoded data in memory seems like a bad idea. I know some programming languages store strings internally in "UTF-8 format" but that never made sense to me. UTF-8 encoded data is binary data. It should be put into an array of bytes or have a new type for it. I definitely don't want to accidentally mix "normal" strings of (decoded) characters with UTF-8 encoded strings. I have a feeling, Dmitry, this is what you are also saying. Peter