c-ares / c-ares / 29194961879

90%

Build Type

push

github

Committed by web-flow

Commit Message

ares_hosts_file: store /etc/hosts as a bipartite adjacency (fixes #1049) (#1233)

Fixes #1049.

## Problem
`/etc/hosts` entries were merged into a single record whenever they were
transitively connected through a shared address, and lookups returned
that record's **union**. Two failure modes:
1. **Leak:** a forward lookup returned addresses belonging to
*unrelated* hostnames that merely shared an address (the reported
symptom — `mullvad-no-svg` returned `mullvad-no-osl`'s addresses).
2. **Dropped "bridge" lines:** a line whose address already belonged to
one entry and whose hostname to another was discarded entirely by the
merge's first-match-wins rule, silently losing that address (the
reporter's fallback `10.64.0.1 mullvad-no-svg` never applied).

## Approach: bipartite adjacency
The data is a set of `(hostname, address)` edges, one per line-token.
Store them directly and index both ways:
- `hosthash`: hostname → list of its addresses (file order)
- `iphash`: address → list of its hostnames (file order)

A lookup builds a correctly-scoped result on demand — forward returns
the queried name's **own** addresses plus **address-scoped** aliases
(names sharing one of those addresses); reverse returns the queried
address and its own hostnames. This is **correct by construction**:
bridges, chains, cross-family merges, and reverse lookups all resolve
the way glibc's `multi on` does, with no merging, filtering, or dropped
lines. `to_addrinfo`/`to_hostent` go back to simple consumers.

> **Note:** an earlier revision of this PR kept the merged store and
filtered results at lookup time to save memory. Review found that
approach could not represent bridge lines (it inherited the merge's drop
behavior), leaving #1049 only ~90% fixed. This revision replaces it with
the bipartite model, which fully fixes it.

## Memory
This is done in two commits so the second can be dropped independently:
1. **the bipartite model** (correctness), and
2. **cached lookup entries** ... (continued)

Coverage Stats

243 of 245 new or added lines in 5 files covered. (99.18%)

16 existing lines in 5 files now uncovered.

25330 of 28099 relevant lines covered (90.15%)

24327.35 hits per line