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-03 20:20:00.000000000 -0400 +++ shadow/82678.tmp.4872 2007-09-03 20:30:17.000000000 -0400 @@ -130,6 +130,28 @@ dirent)', and malloc(3) _that_ size. (Though pathconf(3) may not have a value for _PC_PATH_MAX -- you'd have to check.) Is there any source indicating that the character array is the preferred approach, despite no mention of this "hack" from the actual Unix03 standard for readdir_r()? + +------- Additional Comments From [EMAIL PROTECTED] 2007-09-03 20:30 ------- +And having read the URL you refer to... + +My suggestion to use pathconf(3) seems to be somewhat suspect, as it's +an attack vector (if an attacker changes the filesystem from +underneath you). + +Which pretty much points out that this is an impossible to solve this +problem from user code, as there's no way to know how large a buffer +to allocate (consider GNU Hurd which is supposed to have no filename +limits), no way to safely determine this at runtime, and NO +documentation in the standard readdir_r() docs to suggest that any of +this is the case. + +In short readdir_r() is horribly broken UNLESS the local libc +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. :-( _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
