public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "jg at jguk dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sources.redhat.com
Subject: [Bug libc/9819] readdir segmentation faults when passed NULL
Date: Fri, 28 Oct 2011 23:59:00 -0000	[thread overview]
Message-ID: <bug-9819-131-UUkyrf56AV@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-9819-131@http.sourceware.org/bugzilla/>

http://sourceware.org/bugzilla/show_bug.cgi?id=9819

--- Comment #6 from Jon Grant <jg at jguk dot org> 2011-10-28 23:59:18 UTC ---
Are you sure printf isn't supposed to be robust and prevent de-referencing a
NULL ptr? It's only following accepted wisdom and POSIX. Many other standard
functions check their params for NULL ptr and return EFAULT. Take read() as a
good example, open a file, pass the handle with NULL buf, and you get -1 and
errno==EFAULT, this is the correct behaviour.

Just looking I see quite a few glibc functions exhibit best-practice: read,
write, fopen

printf robust, but sets errno EINVAL rather than EFAULT. Likewise for closedir.

So that's 5 cases where users are not punished while developers are still
informed about the bad param.

SEGV for bad params definitely is not in the contract of these POSIX
functions... Just see the man pages.

I encourage you to take a look at "man read" which describes when EFAULT is
returned.

re standards specifying what happens to a handle which doesn’t refer to a file,
the man pages are pretty clear. "man read" "man write" errno=EFAULT, -1 is
returned for bad pointers. errno could be set EBADF for NULL fp pointer.

I don't see why fwrite can't check FILE* valid in a table for the whole range
of fp handles in use, in the same way that write() does with fd, the
implementation knows what are valid handles, and will check this when
validating params.


The existing robustness should be applied across glibc interfaces not already
stable. Could even have a policy standard document to outline the position
clearly to describe this best-practice (setting errno EFAULT)?

Re puts() checking param for NULL overhead, have you made measurements? It's
just an if(), couple of machine code instructions, won't be noticeable in any
way unless someone made 100,000 calls.


Browser standards, and quirks mode are an interesting point. That's actually
the reason tolerant, and robust browsers do so well. You've kind of proved my
point, glibc should be robust, and tolerant in all cases, indestructible if
possible. Not pedantic and down-right difficult, doing undocumented SEGV
instead. There is a balance to find, and printf detecting the bad pointer is
that balance, it doesn't use it. Developer realises no output from errno, and
fixes the code, solved. User did not suffer in the meantime.

Another argument akin to this one is making -Werror default, fine in a small
environment, but not in a big codebase where someone’s change in one build will
block everyone else from working until that warning is fixed.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


  parent reply	other threads:[~2011-10-28 23:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-9819-131@http.sourceware.org/bugzilla/>
2011-09-27 21:46 ` jg at jguk dot org
2011-09-28  3:12 ` bugdal at aerifal dot cx
2011-10-03 23:52 ` jg at jguk dot org
2011-10-04  0:36 ` bugdal at aerifal dot cx
2011-10-28 23:59 ` jg at jguk dot org [this message]
2011-10-29  0:19 ` bugdal at aerifal dot cx
2011-11-13  0:51 ` jg at jguk dot org
2014-07-01 20:58 ` fweimer at redhat dot com
2009-02-04 17:53 [Bug libc/9819] New: " rbanfield at weogeo dot com
2009-02-04 18:05 ` [Bug libc/9819] " drepper at redhat dot com

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=bug-9819-131-UUkyrf56AV@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=glibc-bugs@sources.redhat.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.
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 read-only IMAP folder(s) and NNTP newsgroup(s).