From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10345 Path: news.gmane.org!.POSTED!not-for-mail From: Jacob Abrams Newsgroups: gmane.linux.lib.musl.general Subject: Re: vprintf.c bug Date: Tue, 2 Aug 2016 13:02:38 -0700 Message-ID: References: <20160727031700.GX15995@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: blaine.gmane.org 1470168178 20233 195.159.176.226 (2 Aug 2016 20:02:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 2 Aug 2016 20:02:58 +0000 (UTC) Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-10358-gllmg-musl=m.gmane.org@lists.openwall.com Tue Aug 02 22:02:55 2016 Return-path: 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 ) id 1bUftt-0004lj-0k for gllmg-musl@m.gmane.org; Tue, 02 Aug 2016 22:02:53 +0200 Original-Received: (qmail 1719 invoked by uid 550); 2 Aug 2016 20:02:51 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 1701 invoked from network); 2 Aug 2016 20:02:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=clover.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FhVQ7z7AWKHx1FPD6nNrwnxRX+KHn61cdsBxqS7SziU=; b=lP1aoBjVgr+mZz7rmIAPXAh820qEaJp5lZYQ/TtSL7Hoslev6dfInlKEzK1MhYqmhm ajNL8h0i+od7gJGcvVcbKmnBAjtuDzi8DYGPeqfaGV+BkCXz/3UhX+d74aD9WXM8oKZy JQCJD75eaZxf15Q8qAxw5N1l8nCGRmzTMEVg7a1cXkjcLmgNqW7JqeLshrFvnvJUDTTO Vtyp3BhsFpniMbNHzSAZALp5evWRenDhSYAXXlrN37bpixLndcLiqCKRa/j7CUE7RWXk ECC0YZkIcgWP6DlZXBhThUEgzBht7/eRcEzUzRWeupiN7jldyFUQG8h/vPsmemFG56Jj HGpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FhVQ7z7AWKHx1FPD6nNrwnxRX+KHn61cdsBxqS7SziU=; b=XhVxKbB3PeO5xee/fS/PNXTXVaLvRo35GsGhXTB3InYceLMXQeXEgixJTKMFgENLPH hxowfeBjo9ORx1vkUVo39CULqS4Gfh+GwgWwi4h5B2xlZat0BYdgBW3wxn2+m/+i2gPg v7FoPelbPOnJyF+EpfC/vGNxHIneo4BmJS0iUpCG1QXSV81ecbfBusnzyQNQbZuYrA8C monH7yrllF1jb4czj5JgtdEpl1nb8UiJnSz6Lu+VDj6sU+xoMHZQP5wNc1KS0iNX1YzZ S4CYCM4eoC9trszsaJ5hYvzieiVb8AQdzeZx7wSXkR8RmXk+s3HAMP+abzKiIP5HcPjF xIEQ== X-Gm-Message-State: AEkoouvOd4RRI/Gxc07dyYQEYyBX3rtxoesmJovkKd0NK8T3BNUIwsqFFhdBMGcJRWZykbZwfnO2JUhB/HMThBRW X-Received: by 10.55.106.195 with SMTP id f186mr75193297qkc.52.1470168158776; Tue, 02 Aug 2016 13:02:38 -0700 (PDT) In-Reply-To: <20160727031700.GX15995@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:10345 Archived-At: I am on an embedded system with minimal OS so I just defined my own stdout and stderr that redirect to my own UART output function: static FILE uart_stdout = { .fd = 1, .lbf = '\n', .flags = F_PERM | F_NORD, .write = uart_write, .lock = 1, }; static FILE uart_stderr = { .fd = 2, .lbf = EOF, .flags = F_PERM | F_NORD, .write = uart_write, .lock = -1, }; You are saying that buf must point to a memory location but that buf_size may be zero? Jacob jacob@clover.com On Tue, Jul 26, 2016 at 8:17 PM, Rich Felker wrote: > On Tue, Jul 26, 2016 at 03:25:40PM -0700, Jacob Abrams wrote: >> I believe there is a small bug in vfprintf.c >> >> I had to change the if statement from >> >> ret = printf_core(f, fmt, &ap2, nl_arg, nl_type); >> if (saved_buf) { >> >> to >> >> ret = printf_core(f, fmt, &ap2, nl_arg, nl_type); >> if (f->buf == internal_buf) { >> >> Because the saved_buf may be NULL which will result the internal >> buffer being used but the file not being reset properly after the call >> to printf_core. This was discovered while using MUSL v1.1.4 on an OS >> other than Linux. > > Where do you get a FILE with a null f->buf? While it's not written > down anywhere, that breaks a contract expected several other places in > the stdio implementation. If you're trying to use vfprintf.c outside > of musl I think you probably need to disable/remove this buffer > replacement code, which would be poking at the internals of another > stdio implementation in a likely-invalid way. > > Rich