This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Problem with line buffering and getc function on 1.7.33.
- From: Kaz Kylheku <920-082-4242 at kylheku dot com>
- To: cygwin at cygwin dot com
- Date: Sat, 12 Mar 2016 16:37:13 -0800
- Subject: Re: Problem with line buffering and getc function on 1.7.33.
- Authentication-results: sourceware.org; auth=none
- References: <a0c23290b3a8502552dcf149fbfa5f90 at mail dot kylheku dot com> <56E34346 dot 9010000 at gmail dot com> <11ca145175d5b7d15db927c0c1f28b18 at mail dot kylheku dot com> <20160312193946 dot GB3567 at calimero dot vinschen dot de> <20160312222921 dot GD3567 at calimero dot vinschen dot de>
On 12.03.2016 14:29, Corinna Vinschen wrote:
On Mar 12 20:39, Corinna Vinschen wrote:
On Mar 11 16:05, Kaz Kylheku wrote:
> We can reproduce the problem with just file streams using
> a much simpler program:
>
> #include <stdio.h>
>
> int main(void)
> {
> FILE *out = fopen("file", "w+");
> setvbuf(out, (char *) NULL, _IOLBF, 0);
> getc(out);
> clearerr(out);
> fseek(out, 0, SEEK_SET);
> putc('a', out);
> putc('b', out);
> putc('c', out);
> putc('d', out);
> putc('e', out);
> putc('\n', out);
> fclose(out);
> return 0;
> }
>
> The contents of file end up being "\n": one empty
> line, instead of "abcde\n":
>
> $ cat file
>
> $
Thanks for the testcase. I can reproduce the issue and I see where
the
problem occurs, but I'm still puzzled. Comparing the code in our
newlib
C library with its BSD counterparts, I could swear the same behaviour
happens on OpenBSD as well. If not (which needs testing), I wonder
why
and where newlib's actually different. Right now I don't see the
difference.
I do now. Basically it's setvbuf screwing up the internal flags in the
FILE structure. I took the liberty to update newlib's setvbuf to the
OpenBSD version locally and I'm going to apply my patches to newlib
soon. I'll provide a new 2.5.0 test release of Cygwin with this patch
tomorrow or early next week.
Indeed, I thought it would have something to do with the
stream->_flags, because when I single-stepped over the getc(stream)
line (necessary for the problem to repro, IIRC) the only apparent state
change in the stream was to the _flags member:
(gdb) n
8 getc(out);
(gdb) p *out
$2 = {_p = 0x80039c28 "", _r = 0, _w = 0, _flags = -30575, _file = 3,
_bf = {
^^^^^^^^^^^^^^^^
_base = 0x80039c28 "", _size = 1024}, _lbfsize = -1024, _data = 0x0,
_cookie = 0x80039a30, _read = 0x61164cb0 <__sread>,
_write = 0x61164f30 <__swrite64>, _seek = 0x61164e50 <__sseek>,
_close = 0x61164ea0 <__sclose>, _ub = {_base = 0x0, _size = 0}, _up =
0x0,
_ur = 0, _ubuf = "\000\000", _nbuf = "", _lb = {_base = 0x0, _size =
0},
_blksize = 0, _flags2 = 0, _offset = 0, _seek64 = 0x61164ed0
<__sseek64>,
_lock = 0x80039bf8, _mbstate = {__count = 0, __value = {__wch = 0,
__wchb = "\000\000\000"}}}
(gdb) n
9 clearerr(out);
(gdb) p *out
$3 = {_p = 0x80039c28 "", _r = 0, _w = 0, _flags = -22347, _file = 3,
_bf = {
^^^^^^^^^^^^^^^^^^
_base = 0x80039c28 "", _size = 1024}, _lbfsize = -1024, _data = 0x0,
_cookie = 0x80039a30, _read = 0x61164cb0 <__sread>,
_write = 0x61164f30 <__swrite64>, _seek = 0x61164e50 <__sseek>,
_close = 0x61164ea0 <__sclose>, _ub = {_base = 0x0, _size = 0}, _up =
0x0,
_ur = 0, _ubuf = "\000\000", _nbuf = "", _lb = {_base = 0x0, _size =
0},
_blksize = 0, _flags2 = 0, _offset = 0, _seek64 = 0x61164ed0
<__sseek64>,
_lock = 0x80039bf8, _mbstate = {__count = 0, __value = {__wch = 0,
__wchb = "\000\000\000"}}}
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple