From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10346 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: vprintf.c bug Date: Tue, 2 Aug 2016 16:11:30 -0400 Message-ID: <20160802201130.GY15995@brightrain.aerifal.cx> 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=us-ascii X-Trace: blaine.gmane.org 1470168713 24953 195.159.176.226 (2 Aug 2016 20:11:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 2 Aug 2016 20:11:53 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: musl@lists.openwall.com To: Jacob Abrams Original-X-From: musl-return-10359-gllmg-musl=m.gmane.org@lists.openwall.com Tue Aug 02 22:11:49 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 1bUg2V-00060i-L1 for gllmg-musl@m.gmane.org; Tue, 02 Aug 2016 22:11:47 +0200 Original-Received: (qmail 7464 invoked by uid 550); 2 Aug 2016 20:11:45 -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 7446 invoked from network); 2 Aug 2016 20:11:45 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:10346 Archived-At: On Tue, Aug 02, 2016 at 01:02:38PM -0700, Jacob Abrams wrote: > 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? Yes. Various places assume that, when the buffer position/limit pointers are null, it means the FILE is not yet in the right state for reading/writing. These pointers are loaded from f->buf, so if f->buf is null, these invariants will be broken. Also note that, for streams open for reading, there must be at least UNGET bytes (8 bytes) of writable memory prior to the buffer f->buf points to; these are not counted in f->buf_size. See stdin.c for an example. Without this space, ungetc will not work (it will clobber other data). Rich