Re: fseek/fgetc puzzle

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



On Mon, Feb 20, 2023 at 06:29:22PM +0100, Gert Doering wrote:
> Having read the thread, the only explanation I can come up is that
> mixing fgetc()/fputc() will somehow confuse the stdio buffering.

Job nerd-sniped me into reading OpenIllumos source code, and from
my reading of

the sequence


will leave "iop->_cnt" at 0 ("one byte read from file, one byte returned,
0 byte left in buffer"), and then

putc_unlocked() will add the new byte to the buffer

    return (*iop->_ptr++ = (unsigned char)ch);

... but nothing actually *resets* the buffer in between.

At "now it's time to write the buffer out" time

fflush() -> _fflush_u() -> _xflsbuf() will do "n = iop->_ptr - iop->_base"
(which is now *2*) and will write out 2 bytes.

Having the fflush() in between seems to reset "iop->_ptr = iop->_base",
so the next fflush() after fputc() only has n = 1.

I haven't actually written a test program that prints out the various
states of iop->_ptr, _base, etc. to verify that assumption.

"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

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

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux