[Mono-bugs] [Bug 82678][Maj] Changed - Mono_Posix_Syscall_readdir_r causes stack corruption in readdir_r, resulting in crash

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by trisk+ximian at acm.jhu.edu.

http://bugzilla.ximian.com/show_bug.cgi?id=82678

--- shadow/82678	2007-09-03 20:30:17.000000000 -0400
+++ shadow/82678.tmp.13033	2007-09-04 06:03:37.000000000 -0400
@@ -152,6 +152,32 @@
 implementation ensures that `struct dirent' contains a local buffer
 that is large enough to hold the maximum path length for that platform
 (which pretty much kills any chance of "no limits").
 
 So I'm still left with not liking the proposed solution and apparently
 unable to accept what should be standard code. :-(
+
+------- Additional Comments From trisk+ximian at acm.jhu.edu  2007-09-04 06:03 -------
+Just to be clear, the readdir_r() behaviour here matches what is
+described in SUSv3, which considers dirent structs to have variable
+size: "The storage pointed to by entry shall be large enough for a
+dirent with an array of char d_name members containing at least
+{NAME_MAX}+1 elements." The readdir_r() manual on Solaris also states
+that the caller is responsible for satisfying this condition and
+unfortunately defines NAME_MAX as pathconf(). 
+
+The readdir_r() interface, by definition, requires an upper bound on
+the length of its returned name. On any platform where this interface
+is available, even if the platform supports unlimited filename or path
+lengths, the returned length must be bounded.
+http://www.mail-archive.com/debian-qt-kde@lists.debian.org/msg17832.html
+ notes that Hurd supports readdir_r() by choosing UCHAR_MAX as an
+arbitrary limit.
+
+I was using PATH_MAX as that is POSIX mandated and I felt it would be
+reasonable on most systems that are able to support Mono, but it's
+clear that readdir_r() is a flawed interface. Could an alternative
+implementation be to use readdir() while performing locking ourselves?
+
+Also, thanks for pointing out the alignment problem in the proposed
+solution. 
+