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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,ee2e271b166c2587 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!s8g2000prg.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Files and controlled types Date: Mon, 10 Mar 2008 08:37:49 -0700 (PDT) Organization: http://groups.google.com Message-ID: <240c1667-3489-4094-9a77-e1284defa88e@s8g2000prg.googlegroups.com> References: <3bd96475-530b-46a7-9b07-11ea49105b2c@e31g2000hse.googlegroups.com> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1205163469 10303 127.0.0.1 (10 Mar 2008 15:37:49 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 10 Mar 2008 15:37:49 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: s8g2000prg.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.7.12-1.3.1,gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:20275 Date: 2008-03-10T08:37:49-07:00 List-Id: On Mar 9, 6:27 am, Maciej Sobczak wrote: > On 9 Mar, 04:12, "Jeffrey R. Carter" > wrote: > > > > File types are not Controlled. > > > What is the rationale for this? > > > What makes you think they're not controlled. > > a) AARM > b) trivial test > > > The ARM only gives the public view, > > which is limited private; there's nothing to prevent the full view from being > > controlled. > > There is nothing that mandates it and therefore I have to assume it is > not done. This is actually what I see in tests. > > > In addition, the descriptions of Ada.Sequential_IO, Ada.Direct_IO, > > and Ada.Text_IO all include the language "The type File_Type needs finalization > > (see 7.6)". > > This is very good - I haven't notice it. > It is very good, because then instead of broken library definition we > can talk about implementation bugs - these are easier to fix. > > My little test follows: > > with Ada.Text_IO; > procedure A is > > procedure New_File (I : in Integer) is > Name : String := "temp/" & Integer'Image (I) & ".txt"; > F : Ada.Text_IO.File_Type; > begin > Ada.Text_IO.Put_Line ("Opening " & Name); > Ada.Text_IO.Create (F, Ada.Text_IO.Out_File, Name); > -- Ada.Text_IO.Close (F); > end New_File; > > begin > for I in -1000 .. -1 loop > New_File (I); > end loop; > end; > > This program creates 1000 files with names "temp/-1000.txt", > "temp/-999.txt", etc. (I use negative counters because I don't want to > waste my time with that useless space in front of the image of > positive integer value). > If the File_Type has finalization, then this program is expected to > finish correctly without the Close call (uncommented above). > On my computer it fails with USE_ERROR after creating 253 files. If we > add the three standard I/O streams, we get a reasonable assumption > that the program has hit an implementation limit (256?) of open file > descriptors. > If I uncomment the Close call, the program properly creates full 1000 > set of files. > I expect Close to be called automatically as part of finalization. I'm not so sure. What happens here? procedure New_File (I : in Integer) is Name : String := "temp/" & Integer'Image (I) & ".txt"; F : Ada.Text_IO.File_Type; begin Ada.Text_IO.Put_Line ("Opening " & Name); Ada.Text_IO.Create (F, Ada.Text_IO.Out_File, Name); Ada.Text_IO.Set_Output (F); end New_File; procedure Proc is begin New_File (-17); Ada.Text_IO.Put_Line ("This is written to default output"); end Proc; New_File will set the current default output file to File. When Proc calls Put_Line, will it then write to that default output file, or will Put_Line raise an exception or be erroneous? I'm not 100% clear on this. Another question is, what do we (as language designers) *want* it to do, or what should it do? But in any case, I haven't seen anywhere in the RM that says that finalizing a File_Type object involves closing it. And examples like this, involving default files or File_Access, show that perhaps you don't *want* files to be closed when File_Type objects are finalized. (The RM phrase that says a File_Type "needs finalization" is, I'm afraid, a smokescreen; this clause has *no* impact whatsoever unless you have a "pragma Restrictions(No_Nested_Finalization)" in effect, which would make it illegal to declare certain File_Type objects. See AI95-360, http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00360.TXT?rev=1.11 . This clause doesn't have any effect on the semantics.) The bottom line is that things just aren't so simple, and it's not obvious whether a File_Type "should" cause a Close when the File_Type is finalized. -- Adam