Hi, On Sat, Sep 29, 2001 at 11:49:36AM -0500, Jacques A. Vidrine wrote: > 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.
Yes, the Single UNIX specification was in error. This error was taken over to POSIX draft 6 (from the Austin group), which also said that hostnames are limited to 255 characters. This was fixed in draft 7 by removing this limit and making HOST_NAME_MAX one of the possible undefined constants, as rightly was pointed out. Obviously the Austin group did not think that any arbitrary limit was desireable. I don't know what exactly their reasons were, but they must have been persuasive, as there is a strong precedent to define and make use of a limit in existing implementations. [...] > OTOH I don't > think that an arbitrarily long hostname makes much sense. [It was pointed out that in the future you might not type in every host name manually, or even generate it manually. There was someone mentioning data being passed as part of the hostname, but I don't have details about it.] > > 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. Well, the only other alternative you have (beside not having heimdal on the Hurd at all, of course) is to not allocate a big enough buffer at run time, which means that not all hostnames acceptable by the system will be accepted. So you are setting an arbitrary constraint to the length of the hostname yourself (which might or might not agree with arbitrary limits imposed by other applications which might choose this hack, confusing the user and leaving him uncertain about any safe limit that will be acceptable to all programs on the system). > On Sat, Sep 29, 2001 at 12:50:59PM +0200, Marcus Brinkmann wrote: > > 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. Ok, so Steven did not anticipate the development of the "constant" that have been performed in the latest draft of POSIX. If he would write the section today, he would certainly make use of HOST_NAME_MAX if defined and use sysconf and the reallocation of the buffer if that returns -1 (after all, this is what he exercises for the other possibly undefined constants as well, so there is no reason why he should treat HOST_NAME_MAX differently). > > but heimdal imposes its own limit constraining the user. > > Don't be silly; it uses what the OS provides, as have countless other > applications. You have misunderstood me. I was assuming that if you don't support arbitrary long hostnames on the Hurd, you would probably just define a limit yourself if the system doesn't provide one. That is the only other way I can imagine to make it at least compile and functional in the common case of short hostnames. But if you have a third solution, I'd be very interested to learn about 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. Well, we claim to be POSIX compliant and I amnot aware of a POSIX incompliance in our interfaces. > POSIX is not UNIX :-) GNU's not UNIX either. Actually, GNU is not POSIX as well, but we accept POSIX as a standard that ensures that system designers and application writers don't need to hash out such details in long discussions. ;) > Personally, in this area, I value: > 1. Portability > 2. POSIX compliance where it does not interfere with (1) > 3. Simplicity If you really value it in this order, then accepting the patch seems to be a straightforward way to increase the value of the code. It achieves portability and POSIX compliance, and frankly I can't see much complexity in the code either. You can verify that it works, and then plug it in whereever it is needed. As we (and many other authors and maintainers) already verified it for you, it is especially easy in this case. > 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. Blame the person who designed gethostname() in the first place, and also the person who copied it into the standard. The interface is broken by design. If it would allocate a large enough buffer for you, it would be much easier (same problem as with getcwd, by the way). 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
