mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: stdio fixes & internals documentation
Date: Thu, 28 May 2015 23:05:16 -0400	[thread overview]
Message-ID: <20150529030516.GB17573@brightrain.aerifal.cx> (raw)
In-Reply-To: <20150529013937.GA32093@brightrain.aerifal.cx>

On Thu, May 28, 2015 at 09:39:37PM -0400, Rich Felker wrote:
> The first thing I want to do is fix the known bug in ungetc, and I
> think the easiest way to do that is to make __toread set valid read
> buffer pointers when it fails due to eof status. Then, instead of
> ungetc checking the return value of __toread, it can instead call
> __toread and then just check rpos. That is, instead of:
> 
> 	if ((!f->rend && __toread(f)) || f->rpos <= f->buf - UNGET) {
> 		// error
> 
> it can instead do:
> 
> 	if (!f->rend) __toread(f);
> 	if (f->rpos <= f->buf - UNGET) {
> 		// error
> 
> or perhaps:
> 
> 	if (!f->rpos) __toread(f);
> 	if (!f->rpos || f->rpos <= f->buf - UNGET) {
> 		// error
> 
> I like the second version better because it does not assume that a
> null pointer compares <= any valid pointer, which could be wrong if
> pointer <= is implemented as a signed comparison. [...]

I have a fix ready to commit here, but sometime between now and
release I think we need some tests for it. The immportant things to
test are that ungetc and ungetwc work correctly on newly-opened files,
files in the middle of reading from the buffer, and files at eof; that
they fail for files not opened in a mode compatible with reading; and
that the new __toread behavior doesn't allow getc or fread to read
when the eof flag is set for the file but the underlying fd has more
data available (in the real world this only happens on terminals or
growing files; the latter would be easier to test I think).

Rich


  reply	other threads:[~2015-05-29  3:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-29  1:39 Rich Felker
2015-05-29  3:05 ` Rich Felker [this message]
2015-05-29  4:32 ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150529030516.GB17573@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).