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