From: jws@hpcljws.HP.COM (John Stafford)
Subject: Re: Ada/UNIX(tm) and the NAME function
Date: 3 Jan 89 20:03:15 GMT [thread overview]
Message-ID: <920006@hpcljws.HP.COM> (raw)
In-Reply-To: 8812281638.AA00722@aries
Relative names:
My interpretation of NAME is that simply attaching the output of
getcwd to a relative name does not meet the specification that "If an
environment allows alternative specification of the name ... , the
string returned by the function should correspond to the full
specification of the name". As noted, on systems with "symbolic
links" and "hidden directories" and the like, it really feels like
such should be "removed" in order to return "the full specification".
Perhaps I am over-reading the RM, I had thought that the spirit of an
RM specification was to be as precise as possible. It is at least
clear that precision is currently not present when using NAME on
UNIX.
I can't imagine any sane program comparing the NAMEs of files,
although certainly an Ada product should document what its version of
NAME does lest somebody think they can reliably do such a thing.
I would like to see NAME return the same thing for a given file no
matter what path I used to open the file (except if such is not
possible, as in the case of hard links). But I suspect I am asking
for more than what is required.
If I open
foo
./foo
./././././././foo
is it reasonable that the result returned by NAME should be different
in each case?
Other issues:
I still don't know what one should do if the file can be opened but
the name cannot be determined (e.g. due to lack of parent directory
access permission).
I also am not "Ada knowledgeable" enough to know that it is OK for
routines which the RM defines as able to raise some exceptions to
raise others as well. I would genuinely appreciate references to why
this is OK (at first glance it would seem to me to make an
implementation of Ada non-conformant if use of NAME could raise
NAME_ERROR).
next prev parent reply other threads:[~1989-01-03 20:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
1988-12-28 16:38 Ada/UNIX(tm) and the NAME function David Emery
1988-12-30 17:35 ` Barry Margolin
1988-12-30 22:08 ` Dik T. Winter
1989-01-03 20:03 ` John Stafford [this message]
-- strict thread matches above, loose matches on Subject: below --
1989-01-01 0:01 Erland Sommarskog
1988-12-20 19:40 John Stafford
1988-12-21 19:43 ` Robert Firth
1989-01-03 15:19 ` Stephe Leake
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox