Jim Meyering <[EMAIL PROTECTED]> writes: > Or maybe you're thinking of a system for which ID_LENGTH_MAX wasn't accurate?
Yes, that's it. > I suppose the Hurd may not define LOGIN_NAME_MAX, or may define it > to be very large. I don't have access to a Hurd system so can't check that. Yes, that's the basic idea. If there is no practical limit to login name length, then POSIX says that LOGIN_NAME_MAX is supposed to be undefined. But the old coreutils code assumes a maximum value of 9 (or perhaps 17) in that case, which is obviously bogus. > Does the Hurd -- or any system -- really let struct passwd's pw_name > point to a string of length INT_MAX? glibc's sysdeps/mach/hurd/bits/local_lim.h indicates that the Hurd does not define LOGIN_NAME_MAX. Another fix would be to replace "INT_MAX < len" with "INT_MAX <= len" in format_user_width, but that's pretty obscure and anyway I figure it's just as easy to support the case where strlen (name) == INT_MAX as to not support it. I should also mention that, regardless of whether the patch is installed, the code silently stops working when dired_pos overflows. There is no buffer overrun, but the output numbers are wrong. This should get fixed at some point, but it's not as urgent. _______________________________________________ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
