Re: heimdal on GNU HURD

[Marcus Brinkmann]

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 brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de