[I may be a Heimdal developer, but these are just my personal views.] On Fri, Sep 28, 2001 at 05:15:46PM -0700, James Morrison wrote: > I'm posting this message from a heimdal developer to bug-hurd > for discussion on the topic of HOST_NAME_MAX. I don't have a > draft of POSIX so I can't verify this.
I verified it with draft 7 of IEEE Std 1003.1-200x before posting. I also confirmed that previous POSIX standards do not define a suitable constant for gethostname(). And finally, the Single UNIX Specification Version 2 notes that hostnames are limited to 255 bytes. [snip MAXPATHLEN, FILENAME_MAX stuff] On Fri, Sep 28, 2001 at 07:18:04PM -0700, Thomas Bushnell, BSG wrote: > Note that no system is required to define HOST_NAME_MAX, specifically, > if there is no maximum. The situation is just like that for > PATH_NAME_MAX. `Just like' is stretching it by a lot. There's a reason that pathconf and sysconf are two different things. pathconf is for things that can change depending upon the path name; sysconf is for things that could potentially be different between compile-time and run-time (i.e. global system configurable values; also ABI issues). It is reasonable to think that you might need an arbitrarily sized buffer to fit a pathname for some unknown filesystem or some clever use. OTOH I don't think that an arbitrarily long hostname makes much sense. > You are supposed to check for a compile-time constant, which might not > be defined. You can check for a run-time constant with sysconf, and > on the Hurd it will return -1, indicating the absence of any limit. > > If you want the program to be Posix compliant, then you cannot assume > that HOST_NAME_MAX is always defined. I don't think that anyone was suggesting that here. > The correct thing to do is to use the referenced xgethostname, which > calls gethostname in a loop in order to get a big enough buffer. I don't accept that this is the only correct thing to do. On Sat, Sep 29, 2001 at 12:50:59PM +0200, Marcus Brinkmann wrote: > 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. > > 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. > > 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). We're not talking about path lengths. I agree with all the arguments here about path lengths. Stevens says only this about MAXHOSTNAMELEN: ``The maximum size of the hostname is normally the MAXHOSTNAMELEN constant that is defined by including the <sys/param.h> header.'' Pretty simple. [snip] > > > [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 :-) [snip a bunch of posturing] > but heimdal imposes its own limit constraining the user. Don't be silly; it uses what the OS provides, as have countless other applications. Please show me this `oppressed' user that wants the astronomically long hostname that mostly won't work anyway because of protocol limitations. > We have already fixed a lot of such ignorant applications, and usually the > authors and maintainers are happy to accept the patches. I was quite happy to have the problem (with MAXHOSTNAMELEN) pointed out. I am not happy to add new complexity to applications for no gain. > 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. It is laudable that you want to do away with `arbitrary limits', and it is laudable that you (apparently) want to be POSIX-compliant. I think it is shameful, however, that the Hurd will not define MAXHOSTNAMELEN or even HOST_NAME_MAX: this seems to be biting the thumb at portability. POSIX is not UNIX :-) Personally, in this area, I value: 1. Portability 2. POSIX compliance where it does not interfere with (1) 3. Simplicity For gethostname, one can use it in a manner that is portable, POSIX-compliant, and simple by using the appropriate constant (which is defined by the OS). Unlike the case with pathnames, there does not seem to be any benefit in adding complexity to support lengths longer than the minimum specified by POSIX. I don't really have a `problem' with implementing functionality similar to xgethostname -- I just think that it is rather silly to jump through such hoops for a basic operation. Lastly, this in no way means that it acceptable for Heimdal to be broken on the Hurd. It will be fixed one way or another. Cheers, -- Jacques A. Vidrine <[EMAIL PROTECTED]> http://www.nectar.com/ Verio Web Hosting = FreeBSD UNIX = Heimdal Kerberos [EMAIL PROTECTED] = [EMAIL PROTECTED] = [EMAIL PROTECTED] _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
