I/O and the LRM

I/O and the LRM

[Jeff Etrick]

 The following is taken from the LRM:

>>function NAME(FILE : in FILE_TYPE) return STRING;

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

>>The exception STATUS_ERROR is raised if the given file is not open.


 I have used the function successfully many times to get the external
name of a currently opened file but what I don't understand is the
comment about it being used in an open statement. Why would I want to use
this statement in an open since the file must already be opened or
STATUS_ERROR will be raised.

Thanks for the help,

Jeff

Re: I/O and the LRM

[Robert I. Eachus]

In article <206@hathor.CSS.GOV> jeffe@hathor.CSS.GOV (Jeff Etrick) writes:

 >  I have used the function successfully many times to get the external
 > name of a currently opened file but what I don't understand is the
 > comment about it being used in an open statement. Why would I want to use
 > this statement in an open since the file must already be opened or
 > STATUS_ERROR will be raised.

   Because you might want to close the file and open it again?

   Actually this statement is more of a direction to the implementor
of TEXT_IO than to the user.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: I/O and the LRM

[enterpoop.mit.edu!snorkelwacker.mit.edu!stanford.edu!agate!spool.mu.edu!c]

In article <206@hathor.CSS.GOV> jeffe@hathor.CSS.GOV (Jeff Etrick) writes:
> 
> 
>  The following is taken from the LRM:
> 
> >>function NAME(FILE : in FILE_TYPE) return STRING;
> 
> >>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.
> 
> >>The exception STATUS_ERROR is raised if the given file is not open.
> 
> 
>  I have used the function successfully many times to get the external
> name of a currently opened file but what I don't understand is the
> comment about it being used in an open statement. Why would I want to use
> this statement in an open since the file must already be opened or
> STATUS_ERROR will be raised.
> 
> Thanks for the help,
> 
> Jeff

It will take a while to answer your question...

In one application, I found that a temporary file would be useful.
When I discovered that Ada allowed you to create temporary files,
I quickly used this new-found expertise:

    Create (Temp, Out_File);

Of course, my next lesson was quite disheartening:

    -- Much information written to file.
    ...
       Temp_Name : constant String := Name (Temp);
    begin
       Close (Temp); -- Temp is deleted from system!
       Send_Name_To_Sub_Process (Temp_Name);

Yes, as soon as the temporary file is closed, it
was deleted--and not by the system.  I could not use
temporary files to pass data to a subprocess.
(Will this behavior still be allowed in Ada9X?)
AI-00046/06-ra-WJ states:
    1)  An implementation is allowed to delete a temporary file
        immediately after closing it.

Yet, the feature that was so beneficial was that a system
dependent name was available!  So now:

      Create (Temp, Out_File)
      declare
         Temp_Name : constant String := Name (Temp);
      begin
         Close (Temp); -- Temp is deleted from system!
         ...
         Create (Temp, Out_File, Get_Temp_Name);

         -- Much information written to file.

         Close (Temp); -- Temp not deleted!
         Send_Name_To_Sub_Process (Temp_Name);

THEN, THE OTHER PROCESS CAN PERFORM AN OPEN USING THE
STRING FROM A NAME FUNCTION.  Yes, this is convoluted
and not necessarily applicable to a single Ada program
which could be redesigned to use the RESET feature--
but you asked for it!

However, this is still a system dependent feature, because
the same AI states:

    2)  The NAME function is allowed to raise USE_ERROR if
        its argument is associated with an external file
        that has no name, in particular, a temporary file.

Oh, well.

Doug Smith
smithd@software.org

Re: I/O and the LRM

[paladin.american.edu!darwin.sura.net!aplcen.apl.jhu.edu!ddsdx2.jhuapl.edu]

In <1992Dec21.163435.22675@software.org> smithd@software.org (Doug Smith) write
s:

>In article <206@hathor.CSS.GOV> jeffe@hathor.CSS.GOV (Jeff Etrick) writes:
>> 
>> 
>>  The following is taken from the LRM:
>> 
>> >>function NAME(FILE : in FILE_TYPE) return STRING;
>> 
>> >>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.
>> 
>> >>The exception STATUS_ERROR is raised if the given file is not open.
>> 
>> 
>>  I have used the function successfully many times to get the external
>> name of a currently opened file but what I don't understand is the
>> comment about it being used in an open statement. Why would I want to use
>> this statement in an open since the file must already be opened or
>> STATUS_ERROR will be raised.
>> 
>> Thanks for the help,
>> 
>> Jeff

A file can be opened more than once.

For example, to write sequential data to standard out:

  CHSEQ.Create(SysOutfile, CHSEQ.Out_File, Text_IO.Name(Text_IO.Standard_Output
));

A file can be opened with shared access, at least on some systems, by
using the write FORM parameter.

--Thor

Re: I/O and the LRM

[David Emery]

Opening the same external file multiple times within TEXT_IO is
clearly specified as implementation-defined.
				dave