On Fri, Sep 28, 2001 at 05:15:46PM -0700, James Morrison wrote: > However, your 1st note is something I don't agree with. For > example MAXPATHLEN is defined on many systems, but is not the best way > to find the limitations of the system because different filesystems > could have different limits. For example if a GNU/Linux system > has an nfs filesystem mounted from a GNU/Hurd system or any system > with a larger MAXPATHLEN, the program would break when retrieving > a file off the nfs mount when it really shouldn't. This is a > simple plee for the use of pathconf.
Jeames is absolutely right here. And if you use path_conf, you will notice that it might return -1, as it does on the Hurd, indicating that there is no limit on the filesystem denoted by the path. > A note on defined constants, I think FILENAME_MAX is too small on > GNU/Hurd at only 1024. I think something large, as implied by the > documentation of glibc, like 65667 should be used. Sorry, there is a reason why it is 1024 (it's the limit imposed by the remote procedure calls, IIRC). We don't like it that way, but the current calue expresses the current limitation correctly. > --- "Jacques A. Vidrine" <[EMAIL PROTECTED]> wrote: > > Hi, > > > > Thanks for the report. I do not think the answer is to add a new > > API. > > > > Almost all versions of UNIX specify MAXHOSTNAMELEN (see > > [Stevens > > UNPv1]). The Hurd probably should, too. I don't have a copy of Stevens right here, but last time I looked at it, Stevens was very careful with dealing with systems which don't define PATH_MAX (and if I recall correctly, those that do not define MAXHOSTNAMELEN, but I am not sure on that). > > Regardless, the next version of POSIX specifies HOST_NAME_MAX. > > We should probably be using HOST_NAME_MAX instead of MAXHOSTNAMELEN > > in the Heimdal sources, or at least do something such as > > > > #if !defined(MAXHOSTNAMELEN) && defined(HOST_NAME_MAX) > > #define MAXHOSTNAMELEN HOST_NAME_MAX > > #endif > > > > IMHO a system that defines neither MAXHOSTNAMELEN nor HOST_NAME_MAX > > is broken [1]. [cutting signature] > > [1] I'm ignoring the fact that HOST_NAME_MAX is one of the > > many `possibly indeterminate run-time invariant values'. Any > > system designer that requires use of sysconf() for such basic > > constants should be drawn-and-quartered :-) We not only require you to use sysconf, we also let sysconf return -1, to indicate that there is no fixed limit. There is a good reason we do so. First, there really is no limit, so saying that there is a fixed limit although there really is none is simply wrong. So why is there no limit? Because we do not like to impose arbitrary limits on the users. Arbitrary limits always turn out to be too small at some time, and they are a hard limit for scaleability. There is a deeper reason why on the Hurd defining a limit nevertheless would be wrong. The Hurd is a user extensible system. This means that any component of the Hurd system can be ignored/overwritten/replaced by the *users* of the system without restriction and without compromising security. But to make it easier for users to be able to continue the usage of the default libraries and system components, we write those components in the most flexible way, setting as little constraints as possible. One such constrain is the length on hostnames. Of course, people who have excessive needs can always patch and compile their own copy of the applications and run them. However, we would be happy to have the flexibility in the official versions of the software already. We would like to say that the Hurd has no limit on the length of the hostnames and the applications we compile for it don't impose one as well, rather than saying that we don't have any limits, but heimdal imposes its own limit constraining the user. We have already fixed a lot of such ignorant applications, and usually the authors and maintainers are happy to accept the patches. So many programs already support arbitrarty long hostnames on the Hurd. However, as you are already aware of that heimdal is not a POSIX compliant application while the Hurd is a POSIX compliant operating system, and you prefer us to be drawn-and-quartered rather than fixing heimdal, I am not sure what I can say to convince you otherwise, beside trying to explain to you why we don't define an arbitrary limit. I hope you agree after the above explanation that there is really a value in not defining a limit and fixing the applications that can't deal with the lack of it. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
