Ken Hornstein <kenh@pobox.com> writes:
Hrm. I guess I hadn't completely thought about the implications
of how localdomain was implemented; I didn't really think about the
issue of LocalName(0) versus LocalName(1). But your point is well
taken; it doesn't really make sense to apply localdomain to both,
does it? I think that if you're using localname you would be
expected to supply a FQDN, and localdomain should only apply in the
LocalName(1) case.
My gut feeling is that localdomain is so rarely used nowadays that
it's not worth fixing it for 1.5. Thoughts from anyone else? For
post-1.5 I'd be fine with either using localdomain for only the
LocalName(1) case or junking support for it completely. Or perhaps
doing something else altogether. Thoughts?
ISTM there is a fairly clear use-case for using localdomain to fill out
an unqualified hostname returned by getaddrinfo(). I have no idea
whether there are still any platforms on which getaddrinfo() would act
that way, but if there are, they would want this feature. On the other
hand, it's not clear to me what the use-case is for specifying an
unqualified localname and then filling it out with localdomain; why not
just write localname as the FQDN to start with? It seems like the first
method could possibly be useful if there are any places where localname
is used without appending localdomain, but I don't see any such places
in the current code. (Not that I know the code well enough to know
whether there are any non-obvious access paths.)
So AFAICS it makes sense to redefine localdomain as only being used
with the getaddrinfo result. Furthermore, if the LocalName(0) versus
LocalName(1) business is new in 1.5, I'd argue for making the change
now, so that people only have to cope with one behavioral change
not two successive ones.
regards, tom lane
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers