public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "bugdal at aerifal dot cx" <sourceware-bugzilla@sourceware.org> 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 [thread overview] Message-ID: <bug-9819-131-OtSYtU3bji@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 #5 from Rich Felker <bugdal at aerifal dot cx> 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.
next prev parent reply other threads:[~2011-10-04 0:36 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 [this message] 2011-10-28 23:59 ` jg at jguk dot org 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-OtSYtU3bji@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).