From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29925 invoked by alias); 28 Oct 2011 23:59:39 -0000 Received: (qmail 29911 invoked by uid 22791); 28 Oct 2011 23:59:38 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_JG X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 28 Oct 2011 23:59:23 +0000 From: "jg at jguk dot 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 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jg at jguk dot org X-Bugzilla-Status: RESOLVED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: drepper.fsp at gmail dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2011-10/txt/msg00179.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=3D9819 --- Comment #6 from Jon Grant 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=3D=3DEFAULT, 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 close= dir. 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=E2=80=99t refe= r to a file, the man pages are pretty clear. "man read" "man write" errno=3DEFAULT, -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 ran= ge 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 alrea= dy 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 a= ny 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, a= nd 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=E2=80=99s change in on= e build will block everyone else from working until that warning is fixed. --=20 Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=3Demail ------- You are receiving this mail because: ------- You are on the CC list for the bug.