Re: Interpretation of extensions different from Unix/Linux?

[Adam Beneschan <adam@irvine.com>]

On Aug 14, 1:01 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Thu, 13 Aug 2009 23:56:03 -0500, Randy Brukardt wrote:
> > "Dmitry A. Kazakov" <mail...@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.)

I'm not sure I understand just what is being proposed---but if the
idea is that a String type is to be used as an array of UTF-8 octets,
it would definitely be a disappointment.  Abstractly, a String is an
array where each element of the array represents a "character", which
is either one graphic symbol or a control character.  Forcing a String
to represent, basically, an arbitrary sequence of bytes that don't
have any relation to graphic characters, seems like an abomination to
me---the sort of thing a C programmer might do, but that shouldn't be
allowed or encouraged in Ada, and it would sadden me if it were
allowed.  It would be a step toward making Ada "just another
programming language", as Randy put it in another thread.  I think I
could even live with having a routine take an Interfaces.C.char_array
parameter to represent an array of octets.  But not String, please...

                                         -- Adam



>
> >>>> 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*?! (:-))
>
> > 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:"... (:-))
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de