#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