Re: On PATH_MAX

[Alfred M\. Szmidt]

   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
)