#3298: Mutt's way to get the FQDN is broken
---------------------+------------------------------------------------------
Reporter: vinc17 | Owner: mutt-dev
Type: defect | Status: new
Priority: major | Milestone:
Component: mutt | Version: 1.5.20
Resolution: | Keywords:
---------------------+------------------------------------------------------
Comment(by Derek Martin):
{{{
On Thu, Aug 13, 2009 at 08:17:21PM -0000, Rocco wrote:
Using compat.h is a good suggestion, but I didn't use it. :) Instead,
I created addrinfo.h, and put the definition of struct addrinfo in
there. As far as I can see, there is currently no place where other
such structures are defined... If you feel strongly that this should
be called compat.h, feel free to change it. You will obviously need
to change the includes in getdomain.c, getaddrinfo.c, freeaddrinfo.c,
and protos.h.
Of course having two versions of a function can't really happen; the
linker will use whichever one it finds first. As long as they both
work (and they should, so long as their prototypes and the actual data
passed to both are the same), this shouldn't be a problem...
New patch attached, I believe this one is kosher. I can't really
think of a way to test the replacement functions though, since I have
no system that doesn't have the originals. I did test them
individually, and they worked...
A couple of other quick notes:
If getdnsdomainname() fails, the original code sets Fqdn to "@". I
changed this to strdup(Hostname). I believe this is the right thing
to do: If the DNS domain name can not be determined by the host
computer's resolver libraries, then either the system's hostname
resolution is in a broken state, OR DNS domain names are not in use.
Granted, the latter case is exceedingly rare now, but it is a valid
configuration. You don't need DNS for mail to work, particularly if
you're using an internal mail system only. But you DO need a hostname
(node name). :) Leaving the FQDN set to "@" seems not sensible; the
only other option that makes sense to me is to have mutt error out.
Lastly, I intentionally checked HAVE_GETADDRINFO when deciding whether
to include addrinfo.h, even when dealing with freeaddrinfo() instead.
The reality is that it's extremely unlikely that an implementation
will have one and not the other; but even ignoring that, if an
implementation were to provide getaddrinfo() then it MUST define
struct addrinfo. So if you have that function, you have
struct addrinfo, even if you don't also have freeaddrinfo(), which
again, is extremely unlikely.
}}}
--
Ticket URL: <http://dev.mutt.org/trac/ticket/3298#comment:>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
