forwarded message from mouring at etoh.eviladmin.org

[Marcus Brinkmann]

Hi,

On Mon, Jul 23, 2001 at 11:49:29PM -0500, mouring at etoh.eviladmin.org wrote:
> if gethostname() returns failures if the hostname is greater then
> MAXHOSTNAMELEN then this whole issue is moot, and this patch is wrong
> since it creates a case where you have inconsistance behavior between
> platforms.  And if that is the case, I will refuse to apply it.

The point is that in operating systems, hostnames longer than MAXHOSTNAMELEN
are not supported throughout the whole system.  So you get a consistent
breakage (truncation, whatever) in the system.  In the Hurd, the breakage
would only apply to the applications which can't deal.  So if ssh defines
its own arbitrary limit, it could fail where the rest of the Hurd system
wouldn't.  If many programs define their own (probably different) arbitrary
limits, the behaviour of applications would be inconsisten on the Hurd
(so, while you slice it for ssh on several platforms, I slice it for the
Hurd and several applications :)

> I still have to ask the same question I did the last time this was brought
> up.. Who in their right mind would have a hostname/FQDN that is over 256
> characters (using OpenBSD's documented limit)?!  That is over 3 lines
> worth of information to type!!!  There are days I wish I would have bought
> a shorter name then 'eviladmin.org' =)

:)  Well, Mr. Gates questioned who would ever need more than 640k memory.
Of course, as I said in my first mail, nobody does right now, and if you
choose to duck the issue and just define a limit, it will work just fine.
Maybe in three years we have all switched to IPv6, and there are some
(automatically processed) hostnames which are 257 characters long.
Our stance is that we change the code today to deal with any length and not
worry about it anymore.

> I have no problems if we handle ENAMETOOLONG using xgethostname()
> (mirroring naming already used for replacement functions [xstrdup,
> xmalloc, etc]).  However, since OpenBSD currently does not suppot
> ENAMETOOLONG it really should not be in the OpenBSD tree which leaves us
> with 3 unique changes for portable.  Which is tolerable.

I would be very happy about such a change.  I am sorry that you have such
issues with code maintenance, I was not aware of that.

> Until such time we can provide configure.in checks and define such
> limitations in our code if the first assumption is true.  The change would
> require a #define to be set in the configure.in since I know Damien does
> not like blindly setting such variables.

This is a functional work around (until suddenly the world goes mad and asks
for very.long.hostnames ;)

[...]
 
> Then having to tip toe around code for platforms that I
> can't test.  Praying I don't break the platform and it gets released in
> such a broken state in the next release (luckly, we have been doing pretty
> good on testing before a release thanks to the many people who help out!).

If there is nobody testing for the Hurd before a release, maybe we can find
someone who is willing to do that.  Do you have a low volume mailing list
where you announce pre releases for testers?
 
> So, you now understand where I come from. =)

Thanks for the explanation.  I don't envy you :)

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd at debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus at gnu.org
Marcus.Brinkmann at ruhr-uni-bochum.de
http://www.marcus-brinkmann.de