octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: file offsets used by fseek and ftell


From: Schloegl Alois
Subject: Re: file offsets used by fseek and ftell
Date: Sun, 4 Jan 2004 21:15:50 +0100
User-agent: Internet Messaging Program (IMP) 4.0-cvs

Zitat von "John W. Eaton" <address@hidden>:

> On 21-Nov-2003, JD Cole <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]