From octave-maintainers-request at bevo dot che dot wisc dot edu Sun Jan  4 14:16:09 2004
Subject: Re: file offsets used by fseek and ftell
From: Schloegl Alois <alois dot schloegl at tugraz dot at>
To: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
Cc: JD Cole <listguy at transientresearch dot com>,    octave-maintainers mailing 	list <octave-maintainers@bevo.che.wisc.edu>
Date: Sun,  4 Jan 2004 21:15:50 +0100

Zitat von "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>:

> On 21-Nov-2003, JD Cole <listguy at transientresearch dot com> 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'll post a solution on bug_octave that is working for me (using gcc 3.3). I do
not know if it works for 3.4, too. If you are right, and this patch is not
applicable in gcc 3.4, we need to thing about alternative solutions for the
future. What do you think about these approaches?
- replacing C++-streams by standard C functions (fopen, fread, ftell, fseek,
etc.)
- not using gcc 3.4 but gcc 3.2.
- addressing the issue to the gcc/libc/stdlibc++ -develepment team(s)


Alois