From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13040
Path: news.gmane.org!.POSTED!not-for-mail
From: Rich Felker <dalias@libc.org>
Newsgroups: gmane.linux.lib.musl.general
Subject: Re: Possible oversight in setvbuf()
Date: Fri, 13 Jul 2018 22:05:27 -0400
Message-ID: <20180714020527.GG1392@brightrain.aerifal.cx>
References: <20180713144052.GA13099@voyager>
Reply-To: musl@lists.openwall.com
NNTP-Posting-Host: blaine.gmane.org
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="qD3brAgIG4LbUq6d"
X-Trace: blaine.gmane.org 1531533816 20499 195.159.176.226 (14 Jul 2018 02:03:36 GMT)
X-Complaints-To: usenet@blaine.gmane.org
NNTP-Posting-Date: Sat, 14 Jul 2018 02:03:36 +0000 (UTC)
User-Agent: Mutt/1.5.21 (2010-09-15)
To: musl@lists.openwall.com
Original-X-From: musl-return-13056-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jul 14 04:03:32 2018
Return-path: <musl-return-13056-gllmg-musl=m.gmane.org@lists.openwall.com>
Envelope-to: gllmg-musl@m.gmane.org
Original-Received: from mother.openwall.net ([195.42.179.200])
	by blaine.gmane.org with smtp (Exim 4.84_2)
	(envelope-from <musl-return-13056-gllmg-musl=m.gmane.org@lists.openwall.com>)
	id 1fe9uF-0005Gn-IN
	for gllmg-musl@m.gmane.org; Sat, 14 Jul 2018 04:03:31 +0200
Original-Received: (qmail 26396 invoked by uid 550); 14 Jul 2018 02:05:39 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Original-Received: (qmail 26375 invoked from network); 14 Jul 2018 02:05:39 -0000
Content-Disposition: inline
In-Reply-To: <20180713144052.GA13099@voyager>
Original-Sender: Rich Felker <dalias@aerifal.cx>
Xref: news.gmane.org gmane.linux.lib.musl.general:13040
Archived-At: <http://permalink.gmane.org/gmane.linux.lib.musl.general/13040>


--qD3brAgIG4LbUq6d
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Fri, Jul 13, 2018 at 04:40:52PM +0200, Markus Wichmann wrote:
> Hi all,
> 
> ungetc() seems to depend on f->buf pointing UNGET bytes into a valid
> array. fdopen() will provide such a thing. However, setvbuf() will set
> f->buf to the very start of the user provided buffer. Bizarrely, UNGET
> is deducted from the buffer size, but not added to the pointer.
> Oversight or intentional?

I'm committing the obvious fix. Attached is a regression test suitable
for libc-test.

Rich

--qD3brAgIG4LbUq6d
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="setvbuf-unget.c"

// commit: 9cad27a3dc1a4eb349b6591e4dc8cc89dce32277
// ungetc after setvbuf should not clobber memory below buffer
#include <stdio.h>
#include <string.h>
#include "test.h"

int main(void)
{
	char buf[1024] = "hello world";
	setvbuf(stdin, buf+12, _IOFBF, sizeof buf - 12);
	while (ungetc('x', stdin)!=EOF);
	if (strcmp(buf, "hello world"))
		t_error("ungetc clobbered outside buffer: [%.12s]\n", buf);
	return t_status;
}

--qD3brAgIG4LbUq6d--