From: jws@hpcljws.HP.COM (John Stafford)
Subject: Ada/UNIX(tm) and the NAME function
Date: 20 Dec 88 19:40:07 GMT [thread overview]
Message-ID: <920005@hpcljws.HP.COM> (raw)
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
next reply other threads:[~1988-12-20 19:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
1988-12-20 19:40 John Stafford [this message]
1988-12-21 19:43 ` Ada/UNIX(tm) and the NAME function Robert Firth
1989-01-03 15:19 ` Stephe Leake
-- strict thread matches above, loose matches on Subject: below --
1988-12-28 16:38 David Emery
1988-12-30 17:35 ` Barry Margolin
1988-12-30 22:08 ` Dik T. Winter
1989-01-03 20:03 ` John Stafford
1989-01-01 0:01 Erland Sommarskog
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox