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.


  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: 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).