From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23951 invoked by alias); 4 Oct 2011 00:36:48 -0000 Received: (qmail 23937 invoked by uid 22791); 4 Oct 2011 00:36:47 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 04 Oct 2011 00:36:32 +0000 From: "bugdal at aerifal dot cx" To: glibc-bugs@sources.redhat.com Subject: [Bug libc/9819] readdir segmentation faults when passed NULL Date: Tue, 04 Oct 2011 00:36: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: bugdal at aerifal dot cx 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" 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/msg00005.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=9819 --- Comment #5 from Rich Felker 2011-10-04 00:36:28 UTC --- > Re stdio, yes, some already are stable: take printf as a good example in glibc, Thank you for proving my point. Do you have any idea how many buggy applications pass NULL to printf because glibc allows it? Do you have any idea what a pain that is to people trying to use such broken software on other standards-conformant systems that (correctly) don't allow you to printf NULL as "(null)" with %s? If it crashed right away, people would be forced to fix the bugs in their code. My argument is correct and it's rather akin to the argument for browser standards. As long as every browser accepts invalid HTML and renders it its own way matching what the author *using that specific browser* intended it to look like, standards go to hell and every browser ends up having to copy all the other browsers' insane behavior in order to render broken sites "correctly". And often, if several browsers have different and incompatible renderings of invalid HTML, there's no solution without trying to detect which browser the author of the HTML was targeting. The correct solution here is to refuse to render invalid HTML *at all* and simply display an error message in its place. > If pointers are not going to checked, the same could be applied to file > handles, letting them cause crashes. Currently passing read() a bad fd, is > robustly handled by setting EBADF in errno and returning -1. No, this is not allowed. File descriptors are completely different from pointers. They refer to shared/inherited resources, and the standard specifies very specific behavior for what happens when you pass a value which does not refer to an open file. Note that, unlike pointers, it is fundamentally possible, for any integer, to determine whether that integer is a valid file descriptor in the current process, and the interfaces allow you to do this. *Any* invalid file descriptor, not just -1, is detectable as invalid and has well-defined behavior. With pointers on the other hand, and with DIR * in particular, there is fundamentally no way to detect whether a particular pointer value refers to an open directory stream (without imposing major restrictions on the implementation). The same applies to FILE pointers, and many other types of resources. Finally, read again what I said about FILE * and getc/putc. They cannot and will not check for NULL because it would make them significantly slower for no benefit. As-is, glibc's DIR * handling and FILE * handling are analogous; neither does the nonsensical checks for NULL. -- 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.