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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f6f130eea077b8f8 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-05-27 13:57:24 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!hammer.uoregon.edu!enews.sgi.com!tdsnet-transit!newspeer.tds.net!news.binc.net!kilgallen From: Kilgallen@SpamCop.net (Larry Kilgallen) Newsgroups: comp.lang.ada Subject: Re: AI-248 and counting the elements in an external file Date: 27 May 2003 15:57:21 -0500 Organization: LJK Software Message-ID: <$ghCR$mci5sd@eisner.encompasserve.org> References: <$YW1v+vxIWob@eisner.encompasserve.org> <3ECFEB59.4010401@attbi.com> NNTP-Posting-Host: eisner.encompasserve.org X-Trace: grandcanyon.binc.net 1054069002 8244 192.135.80.34 (27 May 2003 20:56:42 GMT) X-Complaints-To: abuse@binc.net NNTP-Posting-Date: Tue, 27 May 2003 20:56:42 +0000 (UTC) Xref: archiver1.google.com comp.lang.ada:37865 Date: 2003-05-27T15:57:21-05:00 List-Id: In article , "Randy Brukardt" writes: > Larry Kilgallen wrote in message ... >>In article <3ECFEB59.4010401@attbi.com>, "Robert I. Eachus" > writes: >>> Larry Kilgallen wrote: >>> >>>> Meaning it is permissible to return the number of 512-byte disk > blocks >>>> (or file-specific-size tape blocks) for this function on VMS ? Or > is the >>>> answer supposed to be normalized to bytes even though the number of >>>> overhead bytes required (and thus the file size) will vary, for > instance, >>>> when copying a file from disk to tape ? > The intent is that it be well-defined (which might include raising > Use_Error if if cannot be figured out, as for a keyboard) for files that > can be read or written by Ada. If Ada doesn't understand the files at > all, then we're not trying to say anything. > > I would expect that this functionality would take more work on some OSes > than it does on Windows or Unix. On the original CP/M, for instance, you > had to figure out the file size by finding out the block size and > multiplying it by the number of blocks. That's fine, and keep in mind > that this result really is intended to report the physical size of the > file, The idea of "physical size -- does not have to accurately represent size of data contained" was not at all clear to me reading AI-248. Is that stated in there, or are there plans for an AI- about AI-248 ?