Re: [gccsdk] Unexpected results with fseek() and SEEK_CUR

On 15/03/15 14:32, Duncan Moore wrote:
> If the file qqq contains the single line:
> abcdefghijklmnopq
>
> then on Cygwin the following program gives what I would expect:
> abcdefghijklmnopq
> abcdefghi
> abcdEfghijklmnopq
>
> but on RISC OS gcc 4.7.4, VirtualRPC-Adjust RISCOS 4.39, ARM 710, the
> last output line is wrong:
> abcdefghijklmnopq
> abcdefghi
> abcdefghijklmEopq
>
> RISC OS seems to be using SEEK_END instead of SEEK_CUR.
> Is this a bug in RISC OS gcc, or is it something that just can't be done
> on RISC OS?

My RPi shows the same thing, so I think this may be a bug and RISC OS
should be capable of it.

Looking in stdio/filbuf.c(fill_buffer) at the end we see:

stream->__offset += count;

This seems odd to me, the file pointer is advanced by the number of
characters read into the file buffer regardless of how many characters
we actually requested.
We can see in stdio.h(struct __iobuf) that __offset is described as
"Current file position of underlying file descr".

getc_unlocked (which is used to implement fgetc) is defined (in
stdio.h) as:

#define getc_unlocked(f) \
((--((f)->i_cnt) >= 0 ? *((f)->i_ptr)++ : __filbuf(f)))

If I change that to:

# define getc_unlocked(f) \
((f)->__offset++,(--((f)->i_cnt) >= 0 ? *((f)->i_ptr)++ : __filbuf(f)))

and comment out the line above in filbuf.c, your program produces the
correct result.
However, I feel that I'm blindly making changes here without fully
understanding what I'm doing; could it be this simple or am I breaking
something elsewhere?
Perhaps somebody else has a better grasp of how stdio works?

Lee.

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK