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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM autolearn=no 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!n75g2000hsh.googlegroups.com!not-for-mail
From: Maciej Sobczak <see.my.homepage@gmail.com>
Newsgroups: comp.lang.ada
Subject: Re: Files and controlled types
Date: Sun, 9 Mar 2008 06:27:48 -0700 (PDT)
Organization: http://groups.google.com
Message-ID: 
 <e1019237-f828-4db1-80d8-666ed82c8858@n75g2000hsh.googlegroups.com>
References: 
 <3bd96475-530b-46a7-9b07-11ea49105b2c@e31g2000hse.googlegroups.com>
	<BAIAj.14527$TT4.474@attbi_s22>
NNTP-Posting-Host: 85.3.200.49
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: posting.google.com 1205069268 26547 127.0.0.1 (9 Mar 2008 13:27:48
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Sun, 9 Mar 2008 13:27:48 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: n75g2000hsh.googlegroups.com; posting-host=85.3.200.49;
	posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US;
	rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12,gzip(gfe),gzip(gfe)
Xref: g2news1.google.com comp.lang.ada:20252
Date: 2008-03-09T06:27:48-07:00
List-Id: <comp.lang.ada>

On 9 Mar, 04:12, "Jeffrey R. Carter" <spam.jrcarter....@spam.acm.org>
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.

So - is it the implementation (GNAT) bug?

Or maybe the finalization is concerned with memory management only
(buffers, etc.) and not with external resources? In that case I
consider it a bug in AARM.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com