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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=mHxfn6OS9pUGLxx7sd0LXmaJViDipcybU5/0hHg7AlKip+eItxmXE
	Yfg73ZM0iGktBqv2kHCIKtucRFtLqQs3gJjOkvjN2E5ET7xRsTXRab0MNEEiOFmC
	eAUCIx92nRs1xlFo0Bk2ZLfl51mKkwKj+Q6gThw7mnb9mt+AaB8vr4=
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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	 bh=mHc6gE6kfp0hMVKYnkyRWPsF6BY=; b=IZhNdMuULy8Kzbr97lzcQlVqdjhp
	jCjn6juaNCIE8yqYnIxxhr+FDOhAAtg0o/w26kG9XgQraVq8MgnYo4+ekZcFEt5v
	Q6YLR4NfiBc4VV7eTSW6qTs2NM5lHMK1ocCy2lLjoGn8U61Gaf6bUlNlzbzSKNOz
	e97y9+fQDM6/uTM=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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=-96.6 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_PBL,RDNS_DYNAMIC,USER_IN_WHITELIST autolearn=no version=3.3.2 spammy=H*i:sk:ebae781, H*f:sk:ebae781, HX-Envelope-From:sk:corinna, Hx-languages-length:2261
X-HELO: calimero.vinschen.de
Date: Sun, 13 Mar 2016 11:47:12 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Problem with line buffering and getc function on 1.7.33.
Message-ID: <20160313104712.GC25791@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
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> <ebae78105462dee607c99bc191f797fc AT mail DOT kylheku DOT com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="bg08WKrSYDhXBjb5"
Content-Disposition: inline
In-Reply-To: <ebae78105462dee607c99bc191f797fc@mail.kylheku.com>
User-Agent: Mutt/1.5.24 (2015-08-30)

--bg08WKrSYDhXBjb5
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mar 12 16:37, Kaz Kylheku wrote:
> 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:
> >>> [...]
> >>> 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.
>=20
>=20
> 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:

The actual problem was that setvbuf set the _lbfsize member to -bufsize
in the _IOLBF case indiscriminately.  This in turn leads to __sputc_r
doing the wrong thing:

  if (--_p->_w >=3D 0 || (_p->_w >=3D _p->_lbfsize && (char)_c !=3D '\n'))
    return (*_p->_p++ =3D _c);
  else
    return (__swbuf_r(_ptr, _c, _p));

Note the check for _p->_w >=3D _p->_lbfsize.  By setting _lbfsize in
setvbuf, what happens is that the first branch is called for all
chars up to the first \n.  However, the *first* call to __sputc_r
is supposed to call __swbuf_r anyway, otherwise bookkeeping is broken.

And that's the major difference to the OpenBSD setvbuf; it only sets
fp->_lbfsize to -bufsize if we're already writing (__SWR flag is set).


Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--bg08WKrSYDhXBjb5
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJW5UUwAAoJEPU2Bp2uRE+gG3cP/0clqnKWXso9bLKcv3hCZ+xn
QybqDtz6G/whVe/cgMHMS3euVM2p/Sl7vQGltobBOGtxEtRd+hxUYlDgnfNaCSJ+
OUP3re7Vkw5sKRuraOtgDyxDbbQZxt+uJVHjwW2/XCYla3P+eatKerqgoXKP/irM
dhkd4CaNaO/WePC1ARBSlMxcDDMoyAqxyu3HMgryWvE9lP7mHVeYL3YNogxSMTM7
DVq1yvaRM27c3uvgZD4w1nyi/jSGcfz00l2DBcpGqAD8LY51Q79czDWgo2mDN0h4
rCQ3DeoHkfDY3a5/yXaLx72x1Tswh8jio4jbdMwKWuCY2oOzZ0KnFwtpeFHfqSoE
lQyqWUWMM6pueBLaiJi9zNCBVKL/er+HqG8lQ6U5EaP+jmns79OEeFJRvX4QM61A
fHulzO/JloNzjdwtvWnprFnS/II0QDA3D5XFFbPo+yDKBhmSny1hdiOvsLq15Jl5
Z2I0xF7sM6Tle5t88MpKCCKecv4US/2kWZpiWnk2X4XPF4rFEaRxPXx3WXX92iaf
MJtV8mVv+2otg7OFOSQs6fqDwODi/HTJ2vKs4Xb3Z8Ggx4BRvRKLsT7k9kQOckpQ
I/nJWCJL0n5bOfJGOxUvQP/ty4U4yII2/OVjav1WerkNIJ9E3o5/CEUC5xUiV60G
ps+6LlPYL5UP7s2KtL6p
=4PKV
-----END PGP SIGNATURE-----

--bg08WKrSYDhXBjb5--