Re: surprise data from Ada.Sequential_IO

[John Perry <john.perry@usm.edu>]

Jeff & Dmitry

On Monday, March 22, 2021 at 12:40:39 PM UTC-5, Jeffrey R. Carter wrote:
> On 3/22/21 6:13 PM, John Perry wrote: 
> > The following worked as expected (sorry for the abbreviations but I think it will be clear): 
> > 
> >>> P1.Create; P1.Write; P1.Close; P2.Open(Append_File); P2.Write; P2.Close;
> This is asking for trouble,
> > 
> > However, this: 
> > 
> >>> P3.Open(Append_File); P3.Write; P3.Close; 
> > 
> > ...wrote a few bytes of junk between T2's data and T3's data.
> which you got. 

Thank you, I got a laugh out of that :-)

> When you open a P3.File_Type with mode Append_File, it expects the file to 
> contain an integral number of values of T3 already. What happens if it doesn't 
> appears to be undefined. 

For Direct_IO I inferred this fact from ARM A.8.3, "the file is viewed as a set of elements occupying consecutive positions in linear order", but I don't see a similar indication for Sequential_IO. Is there a warning in the ARM about this?

(I do see the warning in Barnes' book, which I had consulted! and saw! and decided not to use Direct_IO as a result! but somehow read the same thing about Sequential_IO & either forgot or mis-concluded something. So I acknowledge my stupidity here.)

> Either create a record with components of the the three types, instantiate 
> Sequential_IO for that, and write all three values at once, or use streams for 
> heterogeneous I/O. 

I'll look into Streams, thanks.

john perry