the hostentdb introduced between 4.2 and 4.3
(via af5c6f0c6a )
had several issues:
- it caused breakage on FreeBSD and was commented out there
- prevented usage of the hostdb when proxy_dns was turned off
(issue #42)
- required dynamic memory allocation which was accessed from several
threads
- wouldnt reflect changes to the hosts file made during program run
the only sensible solution is to remove the hostentdb and replace it
with a home-grown hosts parser (we can't use gethostent() since
that would mess up the gethostent()-state from different threads).
the new parser used here is deliberately held simple and only meant
to provide the user with means to reference hardcoded ipv4 addresses
via his hosts file.
fixes#42
the strncpy function is both dangerous and slow.
dangerous because it doesn't do what the naive programmer expects
(bounded strcpy), and slow because it pads the entire bufsize
with zeroes.
sys/poll.h is a glibc legacy alias for poll.h.
the latter is specified by POSIX, the former not.
on glibc one of them just includes the other so it doesnt hurt.
the central dns resolver function proxy_gethostbyname() used
to iterate over the gethostent() db (/etc/hosts) on each dns
request.
since this is not threadsafe, we synchronized access to it
previously using mutexes. the parsing of this file is slow,
and blocking all threads to do it even moreso.
since gethostent_r() is only available on a few platforms,
i decided to read the hostent db once and then use a quick
in-memory lookup on further usage.
+ some further refactoring.
instead of allocating memory in the child, we now use the allocator
thread to do all the necessary allocations himself.
additionally we provide a clean API to query the ip <-> dns mapping.
these functions connect via a pipe to the allocator thread, and
exchange messages.
further cleanup is needed, but it seems to work so far.
thread-safety is not yet guaranteed.
closes#1
this is in order to get irssi, which forks for DNS lookups,
and similar programs, to work as intended.
in a previous attempt i learned that shared memory created in a
child process is not visible to the parent;
in this attempt i spin off a thread from the parent which listens
on a pipe and manages the shared memory allocation from the parent
address-space. however this doesnt work as expected:
memory allocated in the parent after the child forked is not visi-
ble to the child as well.
so what happens is: irssi starts a child process, the thread allocs
memory and hands it to the child, the child attempts to write and
segfaults. however irssi doesnt crash. since now the memory is
already allocated, doing the dns lookup again will succeed.
i.e. the dns lookup works now in irssi by luck.
all but the first dns lookups will suceed.
however this is not good enough for me to be satisfied, i commit
this only for documentation purposes.
it called gethostbyname and expected that the h->h_name was set.
this code path here which gets only active if the passed name
equals the gethostname() result failed to set a couple of values.
additionally fixed usage of strncpy, which causes the entire
memory buffer to be written, even when the string is much shorter.
a similar bugfix was independently discovered by semion laptev, but my
version is threadsafe - his version introduces a new static buffer,
even though we have plenty of thread-safe space reserved exactly
for this usage case, thus causing a regression.
now everythings finally correctly indented and future patches
will not be overshadowed by whitespace noise.
used the following settings
--braces-on-func-def-line
--braces-on-struct-decl-line
--braces-on-if-line
--dont-break-procedure-type
--leave-preprocessor-space
--continue-at-parentheses
-linux
-i8
-brace-indent1
--case-indentation8
--space-after-cast
--line-length120
--no-space-after-for
--no-space-after-if
--no-space-after-while
--leave-optional-blank-lines
--ignore-profile
--space-special-semicolon
--indent-label8
