Initialise padding after the file buffer

[wcawijngaards]

The change initializes the padding after the file buffer. Otherwise checkers report use of uninitialised memory from those bytes. It zeroes the block size after the fread, so it does not have to wipe the entire buffer. For strings, that means the library caller would have to initialize them.

[lemire]

Alternatively, you can silence the sanitizer warnings.

[wcawijngaards]

That is true, tools have options for that. I have not used those before. I think the zero of the padding is the best choice, it is not expensive because only padding per file read, of a couple bytes per 16Kb read, and also provides actual initialization, in a defense in depth sense a good measure. If it was expensive, it can get a configure option for maintenance mode and clean debug output.

[wcawijngaards]

I did a number of speed tests with and without the padding initialization, but I could not get a reading for a speed difference. The speed change is likely very small, less than a percent, and I could not capture it with bunch of Mbs and about a Gb zone file. So I think the speed concern need not be an issue.

[wtoorop]

@wcawijngaards how did you see those read from uninitialized value errors? I'm trying to reproduce, but cannot detect them with valgrind -s and also not when compiling with -fsanitize=address,undefined,leak -fno-sanitize-recover=all

[wcawijngaards]

By running the tests from tpkg. Some routines failed on them. Perhaps dname, testplan_axfr, or unknown_rr or so. I believe it failed for both those debug settings.

[wtoorop]

By running the tests from tpkg. Some routines failed on them. Perhaps dname, testplan_axfr, or unknown_rr or so. I believe it failed for both those debug settings.

Thanks. I'll give running the tpkg tests with -fsanitize=address,undefined,leak -fno-sanitize-recover=all a try then.

[wcawijngaards]

Just a note, this fix is already part of the simdzone version that is in the NSD code repository, and 4.12.0 too. So it does not show them.