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@xxxxxxxxxxxxxx
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
