@MSGID: <kn7mhtF58psU1@mid.individual.net>
5d1cec91
@REPLY: 1@dont-email.me> 199c3b7c
@REPLYADDR Niklas Holsti
<niklas.holsti@tidorum.invalid>
@REPLYTO 2:5075/128 Niklas Holsti
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID:
<kn7mhtF58psU1@mid.individual.net>
@RFC-References: 1@dont-email.me>
1@dont-email.me> 1@dont-email.me>
@TZUTC: 0300
@PID: Mozilla/5.0 (Macintosh; Intel Mac OS X
10.14; rv:102.0) Gecko/20100101 Thunderbird/102.12.0
@TID: FIDOGATE-5.12-ge4e8b94
On 2023-09-23 10:02, J-P. Rosen wrote:
> Le 22/09/2023 ? 22:05, Jeffrey R.Carter a ?crit :
>> On 2023-09-22 21:30, Blady wrote:
>>>
>>> A.10.7 Input-Output of Characters and Strings
>>> For an item of type Character the following procedures are provided:
>>> procedure Get(File : in File_Type; Item : out Character);
>>> procedure Get(Item : out Character);
>>> After skipping any line terminators and any page terminators, reads 
>>> the next character from the specified input file and returns the 
>>> value of this character in the out parameter Item.
>>> The exception End_Error is propagated if an attempt is made to skip a 
>>> file terminator.
>>
>> As you have quoted, Get (Character) skips line terminators. 
>> End_Of_File returns True if there is a single line terminator before 
>> the file terminator, but False if there are multiple line terminators 
>> before the file terminator. So you either have to explicitly skip line 
>> terminators, or handle End_Error.
>>
> And this works only if the input file is "well formed", i.e. if it has 
> line terminators as the compiler expects them to be (f.e., you will be 
> in trouble if the last line has no LF).


Hm. The code I suggested, which handles line terminators separately, 
does work without raising End_Error even if the last line has no line 
terminator, at least in the context of the OP`s program.


> That`s why I never check End_Of_File, but handle the End_Error 
> exception. It always works.


True, but it may not be convenient for the overall logic of the program 
that reads the file. That program often wants do to something with the 
contents, after reading the whole file, and having to enter that part of 
the program through an exception does complicate the code a little.

On the other hand, past posts on this issue say that using End_Error 
instead of the End_Of_File function is faster, probably because the 
Text_IO code that implements Get cannot know that the program has 
already checked for End_Of_File, so Get has to check for that case 
anyway, redundantly.

My usual method for reading text files is to use Text_IO.Get_Line, and 
(I admit) usually with End_Error termination.

 --- Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:102.0)
Gecko/20100101 Thunderbird/102.12.0
 * Origin: Tidorum Ltd (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441