From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 X-Received: by 2002:ad4:46a6:: with SMTP id br6mr971028qvb.61.1616436853748; Mon, 22 Mar 2021 11:14:13 -0700 (PDT) X-Received: by 2002:a25:6b44:: with SMTP id o4mr1134673ybm.161.1616436853544; Mon, 22 Mar 2021 11:14:13 -0700 (PDT) Path: eternal-september.org!reader02.eternal-september.org!feeder1.feed.usenet.farm!feed.usenet.farm!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 22 Mar 2021 11:14:13 -0700 (PDT) In-Reply-To: Injection-Info: google-groups.googlegroups.com; posting-host=2601:3c3:401:f550:9ee:b41e:1376:69a6; posting-account=JSxOkAoAAADa00TJoz2WZ_46XrZCdXeS NNTP-Posting-Host: 2601:3c3:401:f550:9ee:b41e:1376:69a6 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: surprise data from Ada.Sequential_IO From: John Perry Injection-Date: Mon, 22 Mar 2021 18:14:13 +0000 Content-Type: text/plain; charset="UTF-8" Xref: reader02.eternal-september.org comp.lang.ada:61636 List-Id: 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