bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: heimdal on GNU HURD


From: Jacques A. Vidrine
Subject: Re: heimdal on GNU HURD
Date: Sat, 29 Sep 2001 11:49:36 -0500
User-agent: Mutt/1.2.5i

[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 <n@nectar.com>                   http://www.nectar.com/
Verio Web Hosting       =      FreeBSD UNIX      =        Heimdal Kerberos
jvidrine@verio.net      =   nectar@FreeBSD.org   =       nectar@pdc.kth.se



reply via email to

[Prev in Thread] Current Thread [Next in Thread]