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.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!ARIES.MITRE.ORG!emery
From: emery@ARIES.MITRE.ORG (David Emery)
Newsgroups: comp.lang.ada
Subject: re: Ada/UNIX(tm) and the NAME function
Message-ID: <8812281638.AA00722@aries>
Date: 28 Dec 88 16:38:54 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: emery@mitre.org
Organization: The Internet
List-Id: <comp.lang.ada>

This is not a significant problem on Unix.  First, you should get an
absolute pathname to the file.  This should be interpreted according
to Unix semantics.  My understanding of this is that, for a relative
pathname, the effect is as if current value of the process' working
directory is prepended to the relative pathname, converting it to an
absolute pathname.  This is then used to get the file.  (note that
there are plenty of optimizations here, particularly those that
"cache" the path traversal to get to the working directory).  There is
no requirement for Ada to determine the "best" path to a file, only
the absolute pathname used to open the file.

So, the Ada implementation of Text_IO.OPEN (or whatever) does the same
thing.  If the pathname isn't absolute, call Unix.getcwd, append the
pathname to this string, and associate it with the FILE_TYPE object.
(More specifically, store it inside the private FILE_TYPE object.)
Note that there is NO requirement to walk the directory chain.  If
Unix can open the file, then this is a good filename; if Unix cannot
open the file, then of course there is no reasonable name associated
with the FILE_TYPE object.  (So call Unix.open before 'calculating'
the file name.)

TEXT_IO.NAME then looks like 
	return FILE.FILE_NAME;
and NAME_ERROR is raised if file_type.file_name has no 'legal' value.

Of course, you have the potential problem of losing access to the file
during the execution of the process.  (For instance, someone clobbers
/usr).  This will always be true with Unix, so Ada shouldn't attempt
to fix Unix.

Naturally, Robert Firth's comment about exceptions is right on the
money.  

One of the things on our "agenda" for the Ada Binding to POSIX is to
provide a reasonable POSIX "binding" interpretation of Ada's TEXT_IO
in a POSIX environment (things like the meaning of FORM string, etc.)
We will discuss this issue at our next meeting but I would be very
surprised we came up with any other interpretation.  We will have to
think a bit about what is returned by TEXT_IO.NAME(TEXT_IO.STANDARD_INPUT).  
Furthermore, I suspect that we will in general try to better define
and possibly restrict the exceptions that a conforming POSIX
implementation can raise for TEXT_IO operations (e.g. restrict
TEXT_IO.NAME to raising STATUS_ERROR, and then only when the given
file hasn't been opened.)  

			dave emery
			(Technical Co-Editor, IEEE POSIX Ada Binding)
			mitre
			emery@mitre.org (new style)
			emery@mitre-bedford.arpa (old style)
			
"Advertisment": for more information on the POSIX Ada binding, contact
me.  To get on the Email list discussing the binding, send mail to
	posix-ada-request@grebyn.com