Re: Ada/UNIX(tm) and the NAME function

Re: Ada/UNIX(tm) and the NAME function

[Erland Sommarskog]

Dik T. Winter (dik@cwi.nl) writes:
>And note also that getwd (in C terms, getcwd is Fortran I believe) may fail.
>It will do so if the parent directory of one of the directories has
>execute permission only, no read permission.  In that case a file may
>be opened, but it is not possible to get an absolute path name.

I guess this is what happens when you type "pwd" and get something like
"...can't open". This is the occassion when you as VMS-raised person get 
very confused and wonder where you are. Such things just doesn't happen
on that system...
-- 
Erland Sommarskog
ENEA Data, Stockholm              This signature is not to be quoted.
sommar@enea.se

re: Ada/UNIX(tm) and the NAME function

[David Emery]

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

Re: Ada/UNIX(tm) and the NAME function

[Barry Margolin]

In article <8812281638.AA00722@aries> emery@mitre.org writes:
>...  If the pathname isn't absolute, call Unix.getcwd, ...
>Note that there is NO requirement to walk the directory chain.

How do you think Unix.getcwd works?  Most Unix implementations don't
remember the character string used to set the working directory.
Getcwd() walks the directory tree.

Does the specification of the NAME function say how it should interact
with asynchronous renamings?  Must it always return the current name,
or can it just return the name used to open the file?  This goes
beyond Unix, since most OSes allow files that are open to be renamed.
However, if the current name must always be returned, it would be
difficult for Unix to support this.


Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

Re: Ada/UNIX(tm) and the NAME function

[Dik T. Winter]

In article <34974@think.UUCP> barmar@kulla.think.com.UUCP (Barry Margolin) writes:
 > In article <8812281638.AA00722@aries> emery@mitre.org writes:
 > >...  If the pathname isn't absolute, call Unix.getcwd, ...
 > >Note that there is NO requirement to walk the directory chain.
 > 
 > How do you think Unix.getcwd works?  Most Unix implementations don't
 > remember the character string used to set the working directory.
 > Getcwd() walks the directory tree.
 > 
And note also that getwd (in C terms, getcwd is Fortran I believe) may fail.
It will do so if the parent directory of one of the directories has
execute permission only, no read permission.  In that case a file may
be opened, but it is not possible to get an absolute path name.
-- 
dik t. winter, cwi, amsterdam, nederland
INTERNET   : dik@cwi.nl
BITNET/EARN: dik@mcvax

Re: Ada/UNIX(tm) and the NAME function

[John Stafford]

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).

Ada/UNIX(tm) and the NAME function

[John Stafford]

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

Re: Ada/UNIX(tm) and the NAME function

[Robert Firth]

In article <GARY.88Dec15142623@milo.mcs.clarkson.edu> gary@milo.mcs.clarkson.edu (Gary Levin) writes:
>In article <8008@aw.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes:
>   ...
>   The best, in my opinion, is to have the semicolon optional: a newline
>   will terminate the statement if possible.  So you can write
>
>	   x := x+1
>	   y := y+1
>
>   and it works, but
>
>	   x := a0+a1+a2+
>		a3+a4+a5
>
>   also works.  One hardly ever gets this wrong.
>
>However, if you are in an expression oriented language, it is possible
>to get really strange effects here.  I would write the above statement
>as:
>
>	   x := a0+a1+a2
>		+a3+a4+a5;
>
>Having submitted this to Icon, I found that the program didn't work as
>expected.  It took me quite a bit of debugging to find that this was
>being treated as two statements, and so x was only assigned a0+a1+a2.
>Further, I then tried to write this as
>
>	   x := (a0+a1+a2
>		+a3+a4+a5);
>
>and I was informed that I was missing a right parenthesis after a2
>(and before the inserted semicolon).  Note that Icon would correctly
>handle the case of the trailing + as Firth wrote his example.
>
>Generally, I prefer systems that have me say what I mean, rather than
>guess.  And if they must guess, they should have the grace to indicate
>their guesses.
>
>It is certainly possible that Icon no longer suffers from this
>particular lexical/syntactic quirk; I haven't used it in quite a while.
>--
>
>-----
>Gary Levin/Dept of Math & CS/Clarkson Univ/Potsdam, NY 13676/(315) 268-2384
>BitNet: gary@clutx   Internet: gary@clutx.clarkson.edu


Newsgroups: comp.arch,comp.lang.fortran
Subject: Re: Quadruple-Precision Floating Point ?
Summary: 
Expires: 
References: <8561@alice.UUCP>
Sender: 
Reply-To: firth@bd.sei.cmu.edu (Robert Firth)
Followup-To: 
Distribution: 
Organization: Carnegie-Mellon University, SEI, Pgh, Pa
Keywords: REAL*16 hardware? obscure

In article <8561@alice.UUCP> wcs@alice.UUCP (Bill Stewart, usually) writes:
>Are there any machines that implement quad-precision (128-bit) floating
>point numbers in hardware?  Are there any commercial Fortran compilers
>that support it?

Yes to both.  The DEC VAX-11 supports what they call 'H' floating point,
which is 128 bits wide (16 bit exponent and 112 bit mantissa counting
the hidden bit).

The DEC Fortran compiler I believe supports all the VAX floating-point
formats.

Newsgroups: comp.lang.ada
Subject: Re: Ada/UNIX(tm) and the NAME function
Summary: 
Expires: 
References: <920005@hpcljws.HP.COM>
Sender: 
Reply-To: firth@bd.sei.cmu.edu (Robert Firth)
Followup-To: 
Distribution: 
Organization: Carnegie-Mellon University, SEI, Pgh, Pa
Keywords: 

In article <920005@hpcljws.HP.COM> jws@hpcljws.HP.COM (John Stafford) writes:
>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 above seems a reasonable interpretation.  Note that the Ada RM 
does not imply that there is only ONE string that uniquely identifies
the file; it reqires only that the string be a "full" specification,
ie one that does not depend on any hidden variables in the execution
environment of the program (such as the current directory).

>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".

I don't see this at all.  It is necessary merely to "freeze" (by copy,
presumably) any values in the environment on which the interpretation
of the file might depend (eg the current working directory).  It is
not necessary actually to compute the name; that can be done later from
the copied information.

>   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.

Surely the right answer is not to replicate this functionality in "Ada"
(presumably the package body INPUT_OUTPUT is intended), but rather to add
to your Unix system a routine that, when called with a "partial" file
name and an environment, will return some appropriate "full" name.
I fail to see why this process should be inefficient (though of course
on Unix the most surprising things ARE inefficient).

>   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.

An implementation that fails in this way is clearly erroneous. The
appropriate course of action would be to look at alternatives.

>   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.

No: the fact that it is required to raise an exception does not imply
(here or elsewhere) that it is forbidden to raise any otehr exception.

Hope that helps a little.

[idiot fodder - ignore]

programs
should 
do
what
they
are
told
not
what
some
bloody
moron
thinks
would
be
a
good
idea
and
imposes
on
everyone
else

Re: Ada/UNIX(tm) and the NAME function

[Stephe Leake]

In article <8069@aw.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes:

   No: the fact that it is required to raise an exception does not imply
   (here or elsewhere) that it is forbidden to raise any otehr exception.

This sounds dangerous to me; I have always assumed that the
pre-defined packages behaved _precisely_ as specified in the LRM,
_including_ which exceptions may be raised. Thus, if the LRM does not
state that a particular routine may raise an exception, it should not
do so. This is critical in writting exception handlers; we have to
know which exceptions a routine may raise in order to handle them all.

Stephe Leake 	(301) 975-3431 		leake@cme.nbs.gov
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Rm. B-124, Bldg. 220
Gaithersburg, MD  20899