Re: lib/48926: gethostbyname(3) doesn't appear to work under NetBSD-5.2 and NetBSD-6.1.x when hostnames appear only in /etc/hosts

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

The following reply was made to PR lib/48926; it has been noted by GNATS.

From: Brian Buhrow <buhrow%nfbcal.org@localhost>
To: gnats-bugs%NetBSD.org@localhost, lib-bug-people%NetBSD.org@localhost, 
gnats-admin%NetBSD.org@localhost,
        netbsd-bugs%NetBSD.org@localhost
Cc: buhrow%nfbcal.org@localhost
Subject: Re: lib/48926: gethostbyname(3) doesn't appear to work under 
NetBSD-5.2 and NetBSD-6.1.x when hostnames appear only in /etc/hosts
Date: Mon, 23 Jun 2014 09:58:03 -0700

        Hello.  There are two versions of this fix that I've provided.
 Both restore working behavior as it existed in NetBSD-5.1 and before.  Here
 are some assumptions that I see in the historical code that has existed for
 years:
 
 1.  It has been the case for a long time that lines not ending with a
 newline character would not get parsed correctly.
 
 2.  The code assumes the fields on the lines it processes are divided up
 into null terminated strings before it begins its work.
 
        The bug introduced with the changes recently added to gethnamaddr.c in
 the netbsd-5 branch is that prior to that change, the gethostent_r(),
 formerly _gethtent(), used fgets() to fetch the lines from the hosts file.
 Fgets() returns a null terminated string that contains only the line
 requested.  Fgetln(), which is now used in the current version, returns a
 pointer to the first character of the requested line, but the string
 potentially contains the contents of the rest of the file and certainly
 more than just the current line.  In order to deal with that, the new code
 puts a NULL character at the end of the current line.  Unfortunately, the
 character after the end of the current line is the first character of the
 next line of the file.  So, there are 3 ways, as I see it, to fix this
 problem:
 
 1.  Save and restore the first character of the next line before and after
 processing.  this is what my first patch does.  The patch works fine but is
 more invasive than the second patch.
 
 2.  The second patch eats the last character of the current line and avoids
 having to save and restore any values.  By the time we get to the place
 where my patch takes effect in the code, we know we're dealing with a line
 that's not just a comment line, and the code assumes the line either ends
 with a "#" or a newline character, and if it doesn't end with either of
 those two things, the line is ignored.  The second patch I provided still
 does comment processing, assuming the comment begins with a "#" character.
 It does assume the last character of the current line is a "newline", but
 that's not a change from the existing code.
 
 3.  One could create a temporary string by using something like strndup()
 to copy the current line into it and then process that, but my feeling is
 that this would be an expensive operation for not much gain, plus, the
 potential for memory leaks is increased.
 
        So, patch 1 addresses Christos's objection that patch 2 eats the last
 character of the current line.  However, I don't see that as a big problem
 since if the line doesn't end in a newline or a "#" character, it won't get
 processed anyway.  I could live with either patch, but I think patch 2 is
 easier to understand and doesn't break anything that wasn't already broken
 in the pre-existing versions of the code.  In fact, as I think about it,
 fgetln() assumes a line ends with a "newline" and so won't even give back a
 length value that's even close to correct if the lines it's working on
 don't end in newline.  and, just for completeness, I think that's also true
 for fparseln(), but I could be mistaken on that.
 
 -thanks
 -Brian