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=0.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA 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.68.231.138 with SMTP id tg10mr369978pbc.7.1333144388228; Fri, 30 Mar 2012 14:53:08 -0700 (PDT) Path: z9ni20082pbe.0!nntp.google.com!news2.google.com!news4.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: xor Date: Sat, 31 Mar 2012 00:53:06 +0300 Organization: Tidorum Ltd Message-ID: <9tmoa2Fu2tU1@mid.individual.net> 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> Mime-Version: 1.0 X-Trace: individual.net QIA+C+kRJL9+iI5+pZBT5Aie/TwIvndKd5PhLyJt6Vr7Rb6tEr Cancel-Lock: sha1:0KyTvkYNsZFr3C/S6SBZsASeUPk= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2012-03-31T00:53:06+03:00 List-Id: On 12-03-30 02:41 , Randy Brukardt wrote: > "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 agree, but I think it is much more likely that Ada.Streams will encounter such a file, than is the case for Ada.Directories or Ada.Direct_IO. Also, I think that Ada.Direct_IO.Open should raise Use_Error for such files (but this does not seem to be required in the RM). > 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. Agreed. > That said, the OP knows that and it surely is > their decision how to write their code. And now the OP has several ways to find the Size, including some warnings about when these ways may not work (and fstat would not work either). -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .