Re: heimdal on GNU HURD

[Jacques A. Vidrine]

On Sat, Sep 29, 2001 at 07:46:20PM +0200, Marcus Brinkmann wrote:
> 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.  

The error was that a magic number was specified.  The fix was to use a
manifest constant.

> 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.

No, they were not persuasive.  To quote the author's (wollman) report,

 ``At XBD page 424 (<unistd.h>) before line 14818 insert:

    _SC_HOST_NAME_MAX

  At XSH page 1982 (sysconf()) before line 45530 insert:

    {HOST_NAME_MAX}     _SC_HOST_NAME_MAX

  I include the last two changes for completeness only; I do not
  believe that applications are likely to use the sysconf() interface
  for this purpose.''

> 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).

If the  Hurd will  not define  MAXHOSTNAMELEN nor  HOST_NAME_MAX, then
indeed there really isn't a good  choice.  We'd have to use sysconf or
_POSIX_HOST_NAME_MAX  or what  we `know'  _POSIX_HOST_NAME_MAX to  be.
I think it's a pity.

> 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).

Yes, this is true.  He dutifully  documents all the details, no matter
how distasteful they may be.

> 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.  

`short hostnames'?  You act as if this would be considered a short
hostname: 
  
aardvark.baahling.caatinga.dabbling.earjewel.fabiform.gabbroic.habanera.ianthine.jabberer.kadikane.labdanum.macaasim.nabobery.oafishly.pabulary.quackery.rabatine.sabadine.tabanuco.ubiquity.vacabond.waddling.xanthane.yachtdom.zaibatsu

Heck, with that one you still have 22 byes left ;-)

In another email you included some  long domain names, the longest one
being  about  111  bytes.   None of  these  exaggerated  domain  names
come even  close to  filling even _POSIX_HOST_NAME_MAX,  and certainly
GNU/Hurd could choose a larger value for HOST_NAME_MAX if this kind of
thing was actually keeping developers up at night.

> But if you have a third solution, I'd be very interested
> to learn about it.

I don't have one.

> > 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.

Actually, it has a few problems:

 = `xgethostname' is a poor name.
 = The semantics  for ensuring  nul-termination are broken  on systems
   that define neither MAXHOSTNAMELEN  nor _SC_HOST_NAME_MAX.  This is
   probably an empty set, but there you are.
 = On that  same set of  systems, where  stupidly long host  names are
   used, calling  xgethostname is expensive because  the function does
   not keep track of how much memory it needed last time.
 = Probably it  shouldn't use realloc -- this can  cause a memory copy
   where one is not needed.

> 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).  

I  could hardly  blame  the person  who  designed gethostname().   The
interface has  worked quite well in  the real world, and  indeed POSIX
has taken  the oppurtuntity to  standardize that interface.   The only
problem is that this was  made a "possibly indeterminate" value, which
IMHO was  a mistake,  albeit one  that it appears  we'll have  to live
with.

Regardless  of  these  academic  arguments,  I  guess  we'll  have  to
implement something  like xgethostname just for  GNU/Hurd, since there
doesn't seem to be any support here for following the rest of the UNIX
world.

Cheers,
-- 
Jacques A. Vidrine <n@nectar.com>                   http://www.nectar.com/
Verio Web Hosting       =      FreeBSD UNIX      =        Heimdal Kerberos
jvidrine@verio.net      =   nectar@FreeBSD.org   =       nectar@pdc.kth.se