I conclude that setting a global PATH_MAX is in general less trouble than not setting it.
It might be less trouble (it is how Debian "fixes" PATH_MAX issues"), but it is the wrong way to go about. While changing all programs to not use a static limit is in general impossible, and not even desirable. Making all programs bug free is in general impossible. But removing limits is desirable, and has always been. You simply do not wisht o have someone tell you that your password can be 8 chars long, or that your music collection isn't allowed to use directory names longer than 2000 chars. And when you do have long filenames, you want programs to handle them, those that don't, are broken and should be fixed. As I said before, even if you define PATH_MAX in glibc, you can _still_ support longer filenames in the filesystem _and_ applications. You seemed to miss the point completely, if you have a PATH_MAX defined, then you have some programs that work with a filename that is PATH_MAX*2 long, and some don't, which will either segfault, or truncate the filename and reporting to the user that it cannot find it. (The claim that just using something like lint will find all those problems is funny, since it won't, unless a far more complex heuristic implemented than the simple one that you suggest. I have found code similar to this in GNU programs, where one shouldn't even be using static limits to begin with: #ifdef PATH_MAX char c[PATH_MAX]; #else char c[4096]; #endif ) _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
