From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!hpda!hpcuhb!hpcllla!hpclisp!hpcljws!jws
From: jws@hpcljws.HP.COM (John Stafford)
Newsgroups: comp.lang.ada
Subject: Ada/UNIX(tm) and the NAME function
Message-ID: <920005@hpcljws.HP.COM>
Date: 20 Dec 88 19:40:07 GMT
Organization: Hewlett-Packard Calif. Language Lab
List-Id: <comp.lang.ada>

Ada I/O has a function NAME which

   "Returns a string which uniquely identifies the external file
   currently associated with the given file (and may thus be used in an
   open operation).  If an environment allows alternative specifications
   of the name (for example, abbreviations), the string returned by the
   function should correspond to a full specification of the name."

So the question is, what should NAME do on a UNIX (tm) system?

   The first interpretation that comes to mind is that NAME should
   return "a" fully rooted path to the given file.  The term "a" is used
   because with hard links there is no "the" fully rooted path to the
   given file.  Futher, on systems which support "alternative
   specifications" like symbolic links or hidden files or alternative
   file system universes, such should be "resolved" and made "explicit"
   in the result.  Things like references to .  and ..  (in the file
   name given to the Ada I/O system by the user) are "alternative
   specifications" as well and should be "resolved" and made "explicit"
   in the result as well.

The problems with that interpretation are:

   1.  The name must be determined when the file is opened/created,
   since the user may have specified a relative file name and may change
   working directory after opening the file and before using NAME.  I
   recognize that changing working directory isn't directly supported by
   Ada, but NAME should work even if the user does change working
   directory since it is to return the "full specification of the name".

   2.  Even if the user gives a rooted path, the work still needs to be
   done to resolve any "alternative specifications".

   3.  The Ada I/O system ends up basically having to implement /bin/pwd
   to walk up the directory tree to compute the fully rooted path.  And
   if it uses chdir(2) during the walk, it also needs to first determine
   the current working directory so that it can "get back there" when it
   is done resolving the path to the specified file.  This potentially
   has severe impact on the performance of all Ada open/create
   operations.

   4.  Lack of read or execute permission anywhere in "a" path to the
   file in question (or to the current working directory in the chdir(2)
   case) will cause this process to fail.  Due to problem 1, it would
   seem that the open/create must therefore fail (probably by raising
   NAME_ERROR), even though the user may have permission to access the
   file and will never need the NAME.

   5.  The error cannot be deferred to the actual use of NAME because
   NAME is not defined as being able to raise any exception except
   STATUS_ERROR and it may only do that if the file is not open.

I am interested in alternative interpretations and/or comments on my
interpretation and comments.  I am also interested in information as to
what current compilers do if anyone cares to share it.  I don't claim to
even know what "Ada should do", but if Ada and UNIX are to get along,
somebody probably will need to take the monkey of defining the behavior
of NAME in a UNIX environment (I am not volunteering, I was referring to
some "official" standards type group, like the Ada/POSIX folks).

--
John Stafford
{biggies}!hplabs!hpda!jws