From octave-maintainers-request at bevo dot che dot wisc dot edu Fri Jan 23 11:11:46 2004 Subject: Re: file offsets used by fseek and ftell From: Alois Schloegl To: "John W. Eaton" CC: octave-maintainers at bevo dot che dot wisc dot edu, bug-octave@bevo.che.wisc.edu Date: Fri, 23 Jan 2004 18:05:12 +0100 John W. Eaton wrote: >On 4-Jan-2004, Schloegl Alois wrote: > >| Zitat von "John W. Eaton" : >| >| > On 21-Nov-2003, JD Cole wrote: >| > >| > | Could this be accomplished using a 64-bit (long long). If I'm >| > | not totally off base, that may be a better solution. >| > >| > With gcc 3.4, streamoff and streampos are classes that hold 64-bit >| > ints (either long long or int64_t). But they are not simple typedefs >| > for either of these types, so it is still not possible to write >| > something like >| > >| > streampos pos = ...; >| > >| > long long ftell_retval = (long long) pos; >| > >| > because there is no way to cast a streampos or streamoff type to an >| > integer. >| > >| > For portability, we can't assume that these types are any particular >| > integer value. Different systems are free to implement streamoff and >| > streampos (or fpos_t if you are using C) in any way they choose >| > (provided that they meet the rather limited constraints of the >| > respective standards). >| >| According to your suggestion in >| http://www.octave.org/mailing-lists/bug-octave/2003/474 >| , I'd like to continue the discussion. >| >| In summary the above statement says, it is not possible to check the >| position of the file pointer like in this (illustrative) example: >| >| pos = ftell(fid); >| if pos == 50, >| fprintf(1,'file pointer points to position 50\n'); >| else >| fprintf(1,'file pointer does not point to 50 but to %i\n',pos); >| end, >| >| This is a major change of the functionality of Octave. I.e it breaks >| at least my libraries (see http://biosig.sf.net/ in case you want to >| know more) which are based on the old FTELL. > >I see now that it is possible to convert an integer to a streampos or >streamoff value, so you can do the comparison above. I've checked in >some changes to allow this. So you can do the following operations >with streamoff objects and integer values: > > +, -, +=, -=, ==, != > >You can also call fseek with an integer value to go to a specific >location in a file given an integer. But you still can't extract an >integer value from a streamoff object, and if you are working with >large files, you might not be able to use an integer value to get to >every location in the file (the int might not be large enough) though >we probably won't encounter this problem for a while. > >I realize that this is a change from the way Octave used to work, >and that it is not fully compatible with Matlab, but is it good >enough? > >jwe > > Thanks for allowing comparisons between STREAMPOS and INTERGER types. In some cases, this fixes the problem; unfortunately, not in every case. Currently, it breaks at the division operator when I do something like this: fpos=ftell(fid); current_block_index = (fpos-headerlength)/blocksize; The natural representation of the position of a file pointer is a numeric value. Therefore, I'm suggesting to return a numeric value. It can take any value between 0 and LENGTH_OF_FILE, -1 can be used to encode errors. The origin for introducing the STREAMPOS object was the ability to access files larger than 4GBytes. If the issue becomes a question whether octave should support, (1) access to files larger than 4GB or (2) FTELL returning a numeric value, I second the later. Alois P.S.: Is there a possibility to convert the STREAMPOS into DOUBLE? Then the limit of filesizes is moved to 2^52 (ca. 4500 (!) Tera ) bytes.