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.
next prev 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: linkBe 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).