fseek/fgetc puzzle

[Gert Doering]

Hi,

On Fri, Feb 17, 2023 at 07:07:12PM +1100, Darren Tucker wrote:
> On some platforms (Solaris, OpenIndiana and AIX) however, the test fails
> because it adds two newlines instead of the expected one.  Basically if
> I fseek to the end, read a byte and write a byte the first byte will
> be duplicated.  I reduced it to this test case:

Having read the thread, the only explanation I can come up is that
mixing fgetc()/fputc() will somehow confuse the stdio buffering.

Googling suggests that this might be a "SysV" thing (Wikipedia lists
"four System V variants: IBM's AIX, ... HP-UX, and Oracle's Solaris,
plus ... illumos").

Of course this made me curious so I ran your (latest) test program
on an ancient SCO OpenServer 5 system I have access to, which is SysVR3
with some R4 bits.  No gcc there, but "stdio surprises" are more a libc
thing anyway.

And lo and behold...

bigbox:/usr/gert$ cc fgetc-test.c 
bigbox:/usr/gert$ ./a.out
fputc A=65
0000000     0041
           A
0000001
fseek=0
c=65
fputc B = 66
bigbox:/usr/gert$ od -x -c testfile
0000000     4141    0042
           A   A   B
0000003


Adding a fflush(f) call after the fgetc(f) will fix the problem
the same way as you reported for Solaris/AIX.

bigbox:/usr/gert$ od -x -c testfile 
0000000     4241
           A   B
0000002


... most interesting.

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
                             Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany                             gert at greenie.muc.de