[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mutt-dev
Subject:    Re: The future of mutt...
From:       Derek Martin <invalid () pizzashack ! org>
Date:       2013-10-04 18:06:35
Message-ID: 20131004180635.GM13440 () dragontoe ! org
[Download RAW message or body]


On Fri, Oct 04, 2013 at 12:06:29PM +0300, Alexander Gattin wrote:
> On Thu, Oct 03, 2013 at 11:16:19PM -0500, Derek
> Martin wrote:
> > What, you want a counter example?
> 
> Yes,
> 
> >   http://dev.mutt.org/trac/ticket/3298
> 
> This one is a miss.

Sorry, you're wrong.  Even if the patch was complete garbage, the
point is there was never any discussion from the devs as to WHY.  It
was completely ignored for three and a half years.  That's exactly the
problem we're discussing.  So no, it's not a miss.

> >  - Had a working patch 4 years ago.  
> 
> I don't like some parts of your original patch too, by the way. 

I don't care if you like it.  The first patch was technically correct
with the trivial exception of having removed the string.h header.
Since strchr() returns an int, and the function was called correctly,
this error has ZERO impact on the patch.  But it's also not
interesting, since there was a new patch within 24 hours.

The only version of the patch which had any technical errors was the
third...  I tried to clean up some of the code which calls this
function, and made a mistake in doing that.  The final version fixes
that.

> MUA may choose to operate offline, so some hacks around libresolv
> (like reading /etc/resolv.conf) are OK instead of just returning -1:

NO, THEY ARE NOT.  If your system is not using DNS for local name
resolution, then using anything in /etc/resolv.conf IS WRONG.  PERIOD.
There are explanations of this in the bug, as well as in the comments
of the last patch.

> Also, the gethostname() method is just plain wrong in many
> situations. 

gethostname() is NEVER wrong; it always gives you the configured
host name of your host.  If that ever returns an answer that's
wrong, then it's because your system is misconfigured.  Go fix it.

Regardless, you clearly fail to understand how the call to gethostname
is being used (in all versions of the patch).  Even if your hostname is
configured wrong, the method I used will still work, so long as your
system is consistently configured wrong.  In other words, it will use
the configured hostname to look up its hostname using your configured
name resolution service.  Internally it looks up the IP associated
with your hostname (which if you are misconfigured, it will most
likely get by looking for a match in /etc/hosts, which is hopefully
likewise misconfigured), and then does a name resolution on that IP
address.  It only uses what gethostname() returns as your domain name
if that name resolution process fails, and the node name contains a
domain.  But if the name resolution process fails, your system is
badly misconfigured.

On hosts which frequently move between networks (and, I would argue,
even on hosts which are fixed to a given network) the configured
hostname should be UNQUALIFIED.  The system should determine its
qualified name via whatever host name resolution mechanism it is
configured to use.  If it does *ANYTHING ELSE* IT IS WRONG.  If you
want Mutt to use something OTHER than what the configured name
resolution system gives you, or the system has no qualified domain
name, you MUST configure Mutt to tell it what to use.

> IMHO it's obvious your patch was wronfg and original implementation
> is correct.

Then you clearly don't understand how hostname resolution works on
Unix systems as well as you think you do.

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.


[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]