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 [EMAIL PROTECTED] http://bugzilla.ximian.com/show_bug.cgi?id=82678 --- shadow/82678 2007-09-04 06:03:37.000000000 -0400 +++ shadow/82678.tmp.15178 2007-09-04 07:56:17.000000000 -0400 @@ -178,6 +178,34 @@ 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. + +------- Additional Comments From [EMAIL PROTECTED] 2007-09-04 07:56 ------- +Indeed, the Solaris readdir_r() man page states ( +http://docs.sun.com/app/docs/doc/816-5168/6mbb3hrpg?a=view): + +"The caller must allocate storage pointed to by entry to be large +enough for a dirent structure with an array of char d_name member +containing at least NAME_MAX (that is, pathconf(directory, +_PC_NAME_MAX)) plus one elements. (_PC_NAME_MAX is defined in +<unistd.h>.)" + +It's _still_ horribly broken, but apparently something like the +original patch must be done. :-/ + +As for using readdir() instead of readdir_r()... Does that actually +work? Trying it as a test case would be an interesting observation +(e.g. see how readdir() handles a 4096-character filename, assuming +your filesystem supports it). I'm not too keen on making readdir() +thread-safe, though, as I've been trying to keep all locking in +Mono.Posix.dll instead of in MonoPosixHelper. (In which case the +"solution" is to just make Mono.Posix.dll use Syscall.readdir() +instead of Syscall.readdir_r()...) + +So if this is the best we can do, which is better: a stack overflow or +a heap overflow? The possibility for overflow _still_ exists, so +we'll have to pick our poison... :-( + + _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
