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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,4f2ff548f619cc58
X-Google-Attributes: gid103376,public
From: Gautier <gautier.demontmollin@maths.unine.ch>
Subject: Re: End of File for streams
Date: 2000/04/17
Message-ID: <38FB5996.C7CCB816@maths.unine.ch>#1/1
X-Deja-AN: 612339662
Content-Transfer-Encoding: 7bit
References: <8df15j$e4b$1@trog.dera.gov.uk>
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
X-Trace: 17 Apr 2000 20:36:07 +0100, mac13-32.unine.ch
Organization: Maths - Uni =?iso-8859-1?Q?Neuch=E2tel?=
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Date: 2000-04-17T00:00:00+00:00
List-Id: <comp.lang.ada>

Kevin Rigotti wrote:

> I have philosophical and aesthetic objections to trapping the
> End_Error exception as a means of determining end of file, but
> is this the only way to do it?

A complement...

- Philosophical ? Is it less tangible or don't you believe it will
work ? No problem, the Manual _guarantees_ that End_Error will be raised
at time!

- Aesthetic ?
    ...
    begin
      for i in inbuf'range loop
        Read( infile, inbuf(i) );
        readpos:= readpos + 1;
      end loop;
    exception
      when End_Error => null;  -- nothing, we just reached EOF
    end;
    ...

______________________________________________________
Gautier  --  http://members.xoom.com/gdemont/gsoft.htm