CVS difference for ai05s/ai05-0049-1.txt
--- ai05s/ai05-0049-1.txt 2007/04/11 00:57:11 1.1
+++ ai05s/ai05-0049-1.txt 2009/11/04 04:01:16 1.2
@@ -1,4 +1,4 @@
-!standard A.16(82/2) 07-04-10 AI05-0049-1/00
+!standard A.16(82/2) 09-11-03 AI05-0049-1/01
!class Amendment 07-04-10
!status work item 07-04-10
!status received 07-02-28
@@ -39,15 +39,129 @@
-** TBD **
+Add a new package Ada.Directories.Hierarchical_Names:
+package Ada.Directories.Hierarchical_Names is
+ function Is_Simple_Name (Name : in String) return Boolean;
+ function Is_Root_Directory (Name : in String) return Boolean;
+ function Is_Relative_Indicator (Name : in String) return Boolean;
+ function Is_Full_Name (Name : in String) return Boolean;
+ function Is_Relative_Name (Name : in String) return Boolean;
+ function Is_Fragment (Name : in String) return Boolean;
+ function Full_Name (Name : in String) return String;
+ function Simple_Name (Name : in String) return String;
+ function Containing_Directory (Name : in String) return String;
+ function Initial_Directory (Name : in String) return String;
+ function Fragment (Name : in String) return String;
+ function Extension (Name : in String) return String;
+ function Base_Name (Name : in String) return String;
+ function Compose (Directory : in String := "";
+ Fragment : in String;
+ Extension : in String := "") return String;
+Hierarchical_Names provides file name construction/decomposition facilities
+for systems with hierarchical file naming. This package is optional, and
+should not be provided on systems that don't have hierarchical file naming.
+AARM Notes: This includes Microsoft Windows, Unix, Linux, and most Unix-like
+systems. These operations are on file names and are purely syntactical;
+there is no requirement that the file or any part of it actually exist.
+Is_Simple_Name returns True if Name is a simple name. Is_Root_Directory returns True
+if Name is syntactically a root (a directory that cannot be decomposed further).
+AARM Note: For Unix, "/" is the root. For Windows, "C:\" and "\\Computer\Share"
+Is_Relative_Indicator returns True if Name indicates navigation within the
+AARM Note: "." and ".." are relative indicators for both Unix and Windows.
+Is_Full_Name is true if the leftmost directory part of Name is a root.
+Is_Relative_Name is true if the leftmost directory part of Name is a relative
+indicator. Is_Fragment is true if Name has proper syntax but is not a
+simple name, full name, or relative name.
+Full_Name, Simple_Name, Extension, and Base_Name work the same as they do in
+Containing_Directory returns the Containing_Directory; it raises Use_Error
+if Name does not identify a containing directory (this includes if
+any of Is_Simple_Name, Is_Root_Directory, or Is_Relative_Indicator are True).
+Initial_Directory returns the leftmost directory part in Name. (That is
+generally a root (for a full name), relative indicator (for a relative name),
+or a simple name (for a fragment)).
+Fragment returns the entire name except the Initial_Directory portion.
+All of the above non-predicates raise Name_Error if the name cannot be
+interpreted as a file name.
+Compose combines the Directory, Fragment, and Extension. The Fragment
+must be a fragment or simple name (relative indicators in the middle of
+paths are a significant security problem), else Name_Error is raised.
+The Directory can be any sort of name, but Name_Error is raised if
+all six predicates would return False. The extension has to represent
+an extension (if not null), else Name_Error is raised.
+AARM Note: There is a set of requirements on what the result is given
+various inputs. For instance, combining a fragment and a simple name
+gives another fragment. See e-mail of Mar 29, 2007 for the details -
+it not shown here yet.
(** TBD **)
+The generalized Compose routine provides the solution to problem (1).
+The function Is_Root_Directory provides the solution to problem (2).
+It would be nice to provide some case sensitivity help for file name
+construction. Unfortunately, it is hard to find anything workable.
+One suggestion has been file name comparison facilities that presumably
+would adjust to the appropriate target semantics. Unfortunately,
+Microsoft recommends that Windows programmers not attempt to compare
+file names. That's because the case-sensitity used is locale-dependent,
+and the locale of a file system is set when it is created: it is not
+necessarily that of the host operating system. (That's even more of a
+problem across networks.) Windows does not provide an API for this purpose.
+We could ignore this problem by saying that the comparison only works for
+Latin-1 file names. But that is obnoxious as Windows supports full Unicode
+An alternative would be to provide a file name normalization function. However,
+normalization can only be done on Windows for files that actually exist (the
+idea is that you look up and return the actual case used by the existing file).
+That does not work in this context (of file name construction) as we want to
+support building names of files that we haven't yet created.
-** TBD **
Questions? Ask the ACAA Technical Agent