X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:subject:mime-version:content-type :content-transfer-encoding:date:from:in-reply-to:references :message-id; q=dns; s=default; b=PiPPaal6WTPX5f3rI5l3K8iZ4Xn4C64 M2LGwn4rlPTYNlspiK5zTU6EKgqngB2+y0MOOfgOBQB88kBE5GybqDc5LX2hAjge 8jxPsxodOjyLCV2Yj5R+BspqvjoEDywqFHYYCnfWg1NOWoDrxyxN4ZFSPTmuto0f rqDpNhYCmOok= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:subject:mime-version:content-type :content-transfer-encoding:date:from:in-reply-to:references :message-id; s=default; bh=yH92iMYLyKiUhUAOMrfm6vwf3ps=; b=vhMIO 2hXdGdgiwRyRwz5EHsFjQS9kgVOwzbQsqZzI5Pva9SdpcMGB9euizbL1Wk35purr jtf1jQtWsF5Vt0xNNZGmVPYpI80CneKwaMaqwOdJBk7f4KdDUkHPd61TCTpvwHSL y+mRHAGh5N0kWDH/ZFQlo/5Sz6Almmk0Ta9Bhs= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,FROM_STARTS_WITH_NUMS,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=liberty, swear, puzzled, H*f:sk:11ca145 X-HELO: smtp-out-so.shaw.ca X-Authority-Analysis: v=2.1 cv=Daa30qZW c=1 sm=1 tr=0 a=WiYoHcCliNeVponEdG0Ckg==:117 a=WiYoHcCliNeVponEdG0Ckg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=SMorJkV_YP8A:10 a=7OsogOcEt9IA:10 a=oKoJVJBDYDjnGgtDEGcA:9 a=QEXdDO2ut3YA:10 To: cygwin AT cygwin DOT com Subject: Re: Problem with line buffering and getc function on 1.7.33. X-PHP-Originating-Script: 501:rcmail.php MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Date: Sat, 12 Mar 2016 16:37:13 -0800 From: Kaz Kylheku <920-082-4242 AT kylheku DOT com> In-Reply-To: <20160312222921.GD3567@calimero.vinschen.de> References: <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> Message-ID: X-Sender: 920-082-4242 AT kylheku DOT com User-Agent: Roundcube Webmail/0.9.2 X-CMAE-Envelope: MS4wfDP9QAlzLyNOEPPn5ac4/ZTiPwPzb6vdqVsfIKsCeWGQXVW03+BhN+chY2WWMAzYofHGX8iYzws5Qg51Ww8E3oc2fl88hJi7qWztFH+6F3GwU8USJ6Xm O6bdueNdhWM6sCnwca2khHYDiimbHnuIukyheqLrpDSDu1gOB+uv2/WK X-IsSubscribed: yes Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id u2D0bY7q029562 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 >> > >> > 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