* vprintf.c bug @ 2016-07-26 22:25 Jacob Abrams 2016-07-27 3:17 ` Rich Felker 0 siblings, 1 reply; 4+ messages in thread From: Jacob Abrams @ 2016-07-26 22:25 UTC (permalink / raw) To: musl 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. Please cc-me on any response. Regards, Jacob jacob@clover.com ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: vprintf.c bug 2016-07-26 22:25 vprintf.c bug Jacob Abrams @ 2016-07-27 3:17 ` Rich Felker 2016-08-02 20:02 ` Jacob Abrams 0 siblings, 1 reply; 4+ messages in thread From: Rich Felker @ 2016-07-27 3:17 UTC (permalink / raw) To: Jacob Abrams; +Cc: musl 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: vprintf.c bug 2016-07-27 3:17 ` Rich Felker @ 2016-08-02 20:02 ` Jacob Abrams 2016-08-02 20:11 ` Rich Felker 0 siblings, 1 reply; 4+ messages in thread From: Jacob Abrams @ 2016-08-02 20:02 UTC (permalink / raw) To: Rich Felker; +Cc: musl 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 <dalias@libc.org> 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: vprintf.c bug 2016-08-02 20:02 ` Jacob Abrams @ 2016-08-02 20:11 ` Rich Felker 0 siblings, 0 replies; 4+ messages in thread From: Rich Felker @ 2016-08-02 20:11 UTC (permalink / raw) To: Jacob Abrams; +Cc: musl 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-08-02 20:11 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-07-26 22:25 vprintf.c bug Jacob Abrams 2016-07-27 3:17 ` Rich Felker 2016-08-02 20:02 ` Jacob Abrams 2016-08-02 20:11 ` Rich Felker
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).