[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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
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,
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
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
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.
Main Index |
Thread Index |