Re: Interpretation of extensions different from Unix/Linux?

On Fri, 14 Aug 2009 18:54:40 -0500, Randy Brukardt wrote:

"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote in message
news:1f999bfa99erz$.9b8p6yymr8x7$.dlg@xxxxxxxxxxxxx
On Thu, 13 Aug 2009 23:56:03 -0500, Randy Brukardt wrote:

"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote in message
news:iavqqy3ue6ne$.uxihdofxdalx.dlg@xxxxxxxxxxxxx
...
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.

But UTF-8 encoded string is a Wide_Wide_String. The elements of a Unicode
string are code points (Wide_Wide_Character). It is only the representation
which is a string of octets (not Character!). Who should care of
representations in Ada?

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.

Shudder, it is C in Ada. Everything is a String... I am using this solution
for years in my strings edit library. It is inherently unsafe. UTF-8 string
must be a separate from String type.

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

Oh, yes! (:-))

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.

Maybe, but these are not "true" roots of the file system.

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.

Yes, this is a problem. Presently I am using a wild mixture of Glib and
Ada.Directories to get the functionality I need. Is_Root is among that.

Probably I will drop Ada.Directories altogether because of its useless. The
only thing that holds me is that Glib's volume monitor

http://library.gnome.org/devel/gio/unstable/GVolumeMonitor.html

does not work either.

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 like Ada.Directories...

If Ada.Directories is provided it must be specified as a useful package.
Its implementation under Windows or Unix (of which file system is no less
broken) is not a matter of concern. I see no problem with traps or even Ada
RTL starting processes and system services, if Ada.Directories has been
used by the executable. If it comes with this price I buy it. What I do not
buy is writing OS-dependent code myself.

[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.]

No need to change, just overload it.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.

Relevant Pages

  • Re: Interpretation of extensions different from Unix/Linux?
    ... the use of UTF-8 in this way is the recommendation of the ARG. ... (UTF-8 is a problem of its own in Ada. ... An OS-neutral Ada.Directories would provide enumeration of roots. ... (Windows gives a failure if you try to enumerate an empty floppy disk). ...
    (comp.lang.ada)
  • Re: Interpretation of extensions different from Unix/Linux?
    ... implementations are advised to support UTF-8 encoded file names. ... (UTF-8 is a problem of its own in Ada. ... One of Wide_Wide_String another of an array of octets. ... idea is that a String type is to be used as an array of UTF-8 octets, ...
    (comp.lang.ada)
  • Re: Unicode Delphi Win32 - which approach
    ... I like the backwards compatibility aspects of UTF-8 vs UTF-16. ... The first 256 Unicode characters map to the ANSI character set. ... entire stream> but calling an API 100 times in a loop I can imagine. ... and explicitly contextualise every string. ...
    (borland.public.delphi.non-technical)
  • Re: UTF-8 encoding
    ... I need to pass a UTF-8 encoded writer ... reading that file with the system's default encoding. ... String), but used elsewhere as if it were a StringBuffer. ... There's a very good reason that ...
    (comp.lang.java.programmer)
  • Re: Chinese filenames
    ... Always use simple ASCII characters. ... Ensure your PHP script be properly UTF-8 encoded. ... The name of the file can be acquired as a UTF-8 string: ...
    (comp.lang.php)
Loading