direct access with Intel fortran
in [Fortran]
|
From: Richard Maine on 8 Feb 2010 12:30 James Van Buskirk <not_valid(a)comcast.net> wrote: > "John Paine" <johnpaine1(a)optusnet.com.au> wrote in message > news:4b6fc223$0$12922$afc38c87(a)news.optusnet.com.au... > > > The FILE_STORAGE_SIZE value in the Intel > > intrinsic module (which I didn't even know existed, let alone what it > > might contain) is indeed 8 and the documentation tells me that it is > > measured in bits. So I do have an ability now to ensure that I am > > reading/writing at the position I expect in the stream. Though from the > > context you provide, it's going to be pretty unlikely that it'll be > > anything I don't expect it to be. > > That was one reason why I created a structure that mapped to the whole > header: there was no need to know the details of how to move around > in the file if we were just going to replop the whole blob of data > there at the beginning. Also it modularized the code so that the > WRITE statements that created the dummy and real header wouldn't have > to change even the the header changed. Assuming the header isn't > itself huge, the extra cost of rewriting parts of the header that > were known at file creation time should be negligible. Also see the POS= specifier in the inquire statement. I should have mentioned that before, but I got distracted by more directly answering the question of the file storage unit size instead. By using POS=, you don't have to compute the position; you just ask what it is and you'll get the right answer, avoiding all kinds of potential system dependencies (that mostly won't happen, but with POS= you don't have to worry about the rare cases). -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on 8 Feb 2010 14:59 James Van Buskirk <not_valid(a)comcast.net> wrote: (snip) > That was one reason why I created a structure that mapped to the whole > header: there was no need to know the details of how to move around > in the file if we were just going to replop the whole blob of data > there at the beginning. Two popular file formats that need header information not available until later, TeX's DVI and the ever popular PDF, put the header data at the end. On many systems it is easier to seek and read the end of the file first than it is to overwrite the beginning. > Also it modularized the code so that the > WRITE statements that created the dummy and real header wouldn't have > to change even the the header changed. Assuming the header isn't > itself huge, the extra cost of rewriting parts of the header that > were known at file creation time should be negligible. PDF has the additional feature that one can change or append to the file, in which case a new Table of Contents is written at the end describing both the old and new data. As the TOC has a variable size, it is especially convenient to have it at the end. -- glen
From: glen herrmannsfeldt on 8 Feb 2010 15:11 Richard Maine <nospam(a)see.signature> wrote: (snip) > Also see the POS= specifier in the inquire statement. I should have > mentioned that before, but I got distracted by more directly answering > the question of the file storage unit size instead. By using POS=, you > don't have to compute the position; you just ask what it is and you'll > get the right answer, avoiding all kinds of potential system > dependencies (that mostly won't happen, but with POS= you don't have to > worry about the rare cases). While the OP uses UNFORMATTED in the examples, there is also FORMATTED STREAM. In that case, from 9.5.1.10: "If the file is connected for formatted stream access, the file position specified by POS= shall be equal to either 1 (the beginning of the file) or a value previously returned by a POS= specifier in an INQUIRE statement for the file." This restriction is similar to the restriction C places on text files. I believe that C also allows fseek() to the end of the file, even in the case of text files. -- glen
From: Gordon Sande on 8 Feb 2010 15:22 On 2010-02-08 15:59:22 -0400, glen herrmannsfeldt <gah(a)ugcs.caltech.edu> said: > James Van Buskirk <not_valid(a)comcast.net> wrote: > (snip) > >> That was one reason why I created a structure that mapped to the whole >> header: there was no need to know the details of how to move around >> in the file if we were just going to replop the whole blob of data >> there at the beginning. > > Two popular file formats that need header information not available > until later, TeX's DVI and the ever popular PDF, put the header data > at the end. On many systems it is easier to seek and read the end > of the file first than it is to overwrite the beginning. The PostScript desription that I found indicated that you needed to put the page count at the beginning but a permitted count was "count at end". So technically no but pragmatically yes. It sounds like they would like the count at the beginning but are realistic enough to do the work of reading to the end if instructed. PDF is a number of PS jobs in one file with extra structure. It was easier for me to generate the PS and use one of the PS to PDF utilites to get to PDF. (It also lowered the number of cook books I had to read!) This is a nice example of the use of a flag value. If the page count, or any other size, is known give it but allow a flag value that causes the size to be determined by a file scan. >> Also it modularized the code so that the >> WRITE statements that created the dummy and real header wouldn't have >> to change even the the header changed. Assuming the header isn't >> itself huge, the extra cost of rewriting parts of the header that >> were known at file creation time should be negligible. > > PDF has the additional feature that one can change or append to > the file, in which case a new Table of Contents is written at the > end describing both the old and new data. As the TOC has a variable > size, it is especially convenient to have it at the end. > > -- glen
From: Richard Maine on 8 Feb 2010 15:31
glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > Richard Maine <nospam(a)see.signature> wrote: > (snip) > > > Also see the POS= specifier in the inquire statement.... > > While the OP uses UNFORMATTED in the examples, there is also FORMATTED > STREAM. Yes, but that's a whole different story. Not only does the OP not happen to use it, but it would be completely unsuited to his needs for many reasons, one of them being the one that prompted his question in the first place. He had a problem with Intel's form='binary' truncating the file. Formatted stream can do exactly the same thing. Unformatted stream does not. I might add, even though it has nothing to do with the OP's issues, that the restriction on POS= values in formatted stream is a typical piece of standard-speak. It isn't as though any compiler is actually likely to enforce the requirement that POS= values in a READ must come from previous inquire statements. That isn't anticipated and I'd be surprised to find any compiler bothering to try to enforce it. Seems like that would be a lot of fuss for no useful purpose. The point is much more that if you compute a value some other way (such as by adding up expected byte counts) then you might not end up where you expected (particularly if you didn't correctly account for possible system-dependent record terminators). Accidentally positioning to the middle of a multi-byte datum could be particularly awkward. As long as you have managed to correctly compute a "reasonable" position, I'd be quite surprised if any compiler rejected it. Sure it would be possible for a compiler to keep track of what values had been returned by inquire, but what a pointless implementation mess that would be unless the file structure were strange enough that it took something like that to make POS= work (in which case one might think it more likely that such files would just be declared non-positionable.) -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain |