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 #6 from Jon Grant <jg at jguk dot org> 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==EFAULT, 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 closedir.

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ât refer to a file,
the man pages are pretty clear. "man read" "man write" errno=EFAULT, -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 range
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 already
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 any
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, and
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âs change in one build will
block everyone else from working until that warning is fixed.

-- 
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]