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-23 18:45:51 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!newshub.sdsu.edu!newsfeed2.earthlink.net!newsfeed.earthlink.net!wn14feed!worldnet.att.net!4.24.21.153!chcgil2-snh1.gtei.net!news.bbnplanet.com!chcgil2-snf1.gtei.net!news.gtei.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: 23 May 2003 20:45:48 -0500
Organization: LJK Software
Message-ID: <$YW1v+vxIWob@eisner.encompasserve.org>
References: <MPG.1934e1948ad1faf989709@News.CIS.DFN.DE>
 <ZXzya.660213$OV.619773@rwcrnsc54>
 <prarcv0cidajjkv1t1favsv4ch0qglht1s@4ax.com>
 <x7vof1t780x.fsf@smaug.pushface.org> <qN$+hNiTRFwu@eisner.encompasserve.org>
 <u4r3l5pvw.fsf@nasa.gov> <vct5imh4199m7f@corp.supernews.com>
NNTP-Posting-Host: eisner.encompasserve.org
X-Trace: grandcanyon.binc.net 1053740657 11366 192.135.80.34 (24 May 2003
 01:44:17 GMT)
X-Complaints-To: abuse@binc.net
NNTP-Posting-Date: Sat, 24 May 2003 01:44:17 +0000 (UTC)
Xref: archiver1.google.com comp.lang.ada:37728
Date: 2003-05-23T20:45:48-05:00
List-Id: <comp.lang.ada>

In article <vct5imh4199m7f@corp.supernews.com>, "Randy Brukardt" <randy@rrsoftware.com> writes:
> Stephen Leake wrote in message ...
>>Kilgallen@SpamCop.net (Larry Kilgallen) writes:

>>> That is straightforward for a file of some record type, or a file of
>>> integers, but what if the file is one created with Ada95 stream
>>> semantics ?
>>
>>It makes no difference. All of these types must be converted to raw
>>stream elements (bytes) before they can be written to the file. That's
>>the nature of files!
> 
> 
> Right, the intent is that this value is whatever the OS returns for the
> file size. That's true for all of the results of this package (with a
> few exceptions). There is no attempt to tie the file size to any other
> Ada semantics (that would be a mess).

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 ?