This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/9819] readdir segmentation faults when passed NULL


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]