Re: /etc/exports is now being read incorrectly

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 23 Dec 2015 16:22:05 +0000 (UTC)
    From:        christos%astron.com@localhost (Christos Zoulas)
    Message-ID:  <n5ehnd$7jk$1%ger.gmane.org@localhost>


  | Unfortunately the standards say it should parse that ol'style.

We don't necessarily have to blindly follow standards, we have to agree
that they are sane, and required, given actual current usage.

But in any case, I was not suggesting reverting the change to getaddrinfo().

  | Heh, I put it in solitary confinement for now.

Looks like it has been slightly reformed by the experience too...

While looking there I noticed a couple of nits (that have been there
"forever" - nothing to do with your changes) but that you might want to
fix while cleaning up...

First, the comment (now in get_net.c)

        /*      
         * Only allow /pref notation for v6 addresses.
         */

is total nonsense.   What the code that follows actually does, is
require "/pref" (where "pref" as a name comes from for this purpose
is a whole other issue...) notation (except in the unlikely case that
the -mask option was already processed) for IPv6 addresses.

Aside from the order requirement for IPv6, which doesn't really matter,
as no-one sane would use -mask for IPv6 anyway, this is sensible, as
IPv6 has no "natural" mask length (unless, perhaps, one wanted to
default to /64, and that would be a bad idea) unlike the old address class
stuff from v4 that we have to continue supporting as there must be someone, 
somewhere in the world, who still uses it...

What the comment should probably say is something like

	/*
	 * Disallow v6 addresses without a specific mask or masklen
	 */

Also, even more minor (and again, old) there are space/tab mixups in the
#defines that are now in mountd.h

Lastly, I can fathom no reason at all for all the code calling getnameinfo()
and setting nt_name - as best I can tell, nothing uses it.   It happens only
in a subset of cases, so it is hard to believe that anything depends upon
it that I have missed.   I think I'd just rip all of that nonsense out, and
see what happens...

The other call to getnameinfo() appears to be just to validate that the
address just lovingly extracted from the string is in fact a valid addr.
I'm not sure under what conditions that could fail (what binary addr form
is going to be invald?   (In the sense of getnameinfo(AI_NUMERICHOST)
failing anyway?)   Maybe for some other address family than v4 or v6, but
this code is never going to work for them anyway.   So I think I'd rip
out that one as well.

kre