Re: Interpretation of extensions different from Unix/Linux?

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1f999bfa99erz$.9b8p6yymr8x7$.dlg@40tude.net...
> On Thu, 13 Aug 2009 23:56:03 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:iavqqy3ue6ne$.uxihdofxdalx.dlg@40tude.net...
>> ...
>>> Latin-1 is a limitation that makes impossible to write OS-independent
>>> programs. BTW, I didn't check it but I suppose that the GNAT 
>>> implementation
>>> is not even Latin-1, it is in fact UTF-8, at least under Linux. So it is
>>> broken twice. Once per design, once by the implementation to fix broken
>>> design.
>>
>> Actually, the use of UTF-8 in this way is the recommendation of the ARG. 
>> We
>> have no plans of changing any of the file handling routines away from
>> String. We may add some Implementation Advice to make it clear that
>> implementations are advised to support UTF-8 encoded file names.
>
> The problem is 3.5.2 which claims that Character is Latin-1.
>
> (UTF-8 is a problem of its own in Ada. We need a private type with two
> interfaces. One of Wide_Wide_String another of an array of octets. Ada
> cannot provide this.)

You mean, "Ada cannot provide this optimally". As far as the ARG is 
concerned, a UTF-8 encoded string is a String. We looked at other options 
and decided they weren't worth the effort.

Indeed, we approved the encoding package at the last ARG meeting, so it is 
in the current working draft of the Ada Standard: 
http://www.adaic.com/standards/1zrm/html/RM-A-4-11.html.

So clearly Ada can do this, just not the way you would like to see it done. 
Not the first time. ;-)

>>>>> 3. Even so it provides no way to get the name of the root
>>>>
>>>> Because it is OS neutral, and there is no independent concept of a 
>>>> root.
>>>
>>> An OS-neutral Ada.Directories would provide enumeration of roots. Any
>>> usable Ada.Directories must have the concept of roots nodes.
>>
>> Enumeration of roots is impractible on Windows, because every possible 
>> file
>> share would have to be included in such a list (including any that don't
>> have permissions to read). That would be impossibly slow, and pretty
>> pointless to boot. It also would cause problems with removable disks
>> (Windows gives a failure if you try to enumerate an empty floppy disk). 
>> I've
>> dealt with those headaches from our compiler installer, and I wouldn't 
>> want
>> to force them on other users of Ada.
>
> Same to me. But it is required to make Ada.Directories any usable.
>
> Presently I use Exists in a loop through "A".."Z" + "/". That works both
> under Linux and Windows. Do you think that is *better*?! (:-))

No, actually it is just wrong! There are many roots in Windows that don't 
have the disk name syntax. "C:\" is surely a root, but so is 
\\Gatekeeper\Weblogs\. You can't enumerate roots in Windows, the only 
program that ought to try is Windows Explorer.

You do need to know if you have a root in hand (so you don't try to 
decompose it). I'm tenatively planning to add an Is_Root function to 
Ada.Directories to handle that need.

>> If you can't do it reasonably in Windows, it surely doesn't belong in
>> Ada.Directories.
>
> The MS-explorer does not drop that nasty c0000013 pop up window when
> started. From this I conclude there should be a way to.
>
> Technically, it is certainly possible, for example (a bit exaggerated), do
> system with "cmd" on "dir A:". If the output is "The system cannot find 
> the
> path ,specified." (in the current locale (:-)), there is no "A:". Repeat 
> up
> to "Z:"... (:-))

That's possible to do, but it can only be done by handling traps. And 
handling traps in the Ada runtime system is a bad idea. Moreover, that does 
nothing about enumerating network shares, which is a whol 'nother kettle of 
fish.

This is simply something you shouldn't do (like comparing file names).

[And, yes, I agree with you that they shouldn't even have "=", but blame 
Ichbiah for making these things Strings. It's 25 years to late to change 
that definition.]

                                      Randy.