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.3 required=5.0 tests=BAYES_00,XPRIO_SHORT_SUBJ autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,8f01d35116e753b6 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.204.156.202 with SMTP id y10mr8492bkw.1.1333064497943; Thu, 29 Mar 2012 16:41:37 -0700 (PDT) MIME-Version: 1.0 Path: h15ni64280bkw.0!nntp.google.com!news1.google.com!goblin2!goblin.stu.neva.ru!feeder.erje.net!nuzba.szn.dk!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: xor Date: Thu, 29 Mar 2012 18:41:32 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <9t8mq9Fla4U1@mid.individual.net> <9t99r9F6e2U1@mid.individual.net> <4f72393e$0$6643$9b4e6d93@newsspool2.arcor-online.net> <4f7308a9$0$7625$9b4e6d93@newsspool1.arcor-online.net> <9tgqomFflrU1@mid.individual.net> <9ti9k2FjcvU1@mid.individual.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1333064496 16581 69.95.181.76 (29 Mar 2012 23:41:36 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 29 Mar 2012 23:41:36 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2012-03-29T18:41:32-05:00 List-Id: "Niklas Holsti" wrote in message news:9ti9k2FjcvU1@mid.individual.net... > On 12-03-29 02:25 , Randy Brukardt wrote: >> "Niklas Holsti" wrote in message >> news:9tgqomFflrU1@mid.individual.net... >>> On 12-03-28 18:23 , Michael Moeller wrote: >> ... >>>> I don't want to push your helpfulness to far, but I still don't >>>> know whether there is any means to determine the size of a file >>>> from within Ada other than using a C subroutine calling fstat. >>> >>> Two ways: >>> >>> - Ada.Directories.Size, given the file name. >>> - Ada.Direct_IO.Size, given an open (Direct_IO) file. >> >> Actually, three ways: > > Ok, I showed two ways, but did not mean that there aren't other ways. > >> Ada.Stream_IO.Size, given an open (Stream_IO) file. > > If "positioning is not supported" for the stream file, the result of > Ada.Stream_IO.Size is implementation defined. Positioning is probably > supported for the kinds of files the OP uses now, but it is a bit of trap > for possible future uses of the program, for example if the program is > later used in a shell pipeline. A pipe probably does not support > positioning. I'm pretty sure that if "positioning is not supported" for a particular stream file, none of the other mechanisms will provide any useful answers, either. That's especially true as most Ada compilers use a common I/O system to implement all of these packages, so the effects will be similar on all of them. File for which "positioning is not supported" are likely to be things like sockets, pipes, and devices. Those won't have a meaningful size no matter how they're accessed. I suppose an implementer could make all stream files not support positioning and do something different for Text_IO, but as is commonly mentioned, "implementers don't intentionally cripple their implementations". In any case, your point is really just another argument for not depending upon the size at all; depending on the sort of file, it may not even be a meaningful concept. So depending on the size decreases the utility and reusability of your code. That said, the OP knows that and it surely is their decision how to write their code. Randy.