simon at thekelleys.org.uk
Fri Sep 10 22:32:40 UTC 2021
On 10/09/2021 09:37, Dominik DL6ER wrote:
> I agree this is a good solution, patch attached. I hope to have caught
> all places (I don't have the dependencies to build all possible
> combinations myself).
Ah, thank you! I combined that with the one that started this thread and
I have a tool which builds with all the possible single compile-time
options, and a good selection of combinations (every possible one would
take WAY to long) and it passes fine.
> On Thu, 2021-09-09 at 23:35 +0100, Simon Kelley wrote:
>> querystr becomes a local function to cache.c or just gets rolled into
> I did the former. Merging it into log_query() would make an already
> complex routine even longer.
> Concerning performance: The loop can at most iterate over 89 entries
> before it says: "Didn't find". However, for the vast vast majority of
> cases, the match will be in the first 30ish (AAAA and SRV) as query
> types behind those are not very likely to be seen. The loop breaks as
> soon as the match is found. Looking at the gcc11 x86_64 -O2 assembly,
> there are no surprises, only very few assembler instructions per
> iteration are needed. The next type integers in the table can always be
> found 16 bytes after the former. Hence, we just need
> add rax, 1
> cmp rax, 89
> je .NOT_FOUND
> mov rdx, rax
> movsx rcx, eax
> sal rdx, 4
> cmp DWORD PTR typestr[rdx], r1d
> jne .FOR_LOOP
> [... stuff if found ...]
> Given we call library functions like strlen() and sprintf(), our loop
> here is surely not any kind of bottleneck. Even if it'd be even larger.
Agreed. It's pretty difficult to get into trouble with O(N) where N is
constant and magnitude three.
tagged 2.87-test1 just to get 2.87 into the version string.
Petr - I shall work though your coverity-originated patches as I get
time in the next day or two.
More information about the Dnsmasq-discuss