Re: Why no Ada.Wide_Directories?

["Peter C. Chapin" <PChapin@vtc.vsc.edu>]

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