==Working on another 3.4 release==
While the legacy 3.4 release is mainly only updated with security updates, I have decided to backport the min_ttl parameter from the 3.5 to the 3.4 branch of MaraDNS/Deadwood, since this helps recursive resolvers be more responsive on the modern Internet.
While using Deadwood as a recursive resolver is generally deprecated—recursive DNS here in 2022 is something best left to large organizations which can pay programmers to maintain the DNS server full time—this is a fairly small change which will make things more bearable for people still using Deadwood 3.4 as a recursive resolver.
Since the 3.4 branch of MaraDNS uses a system of shell scripts and diff patches to update the code, I have made a script which will update Deadwood with this change when it is time to make the MaraDNS 3.4.04 release.
In the meantime, the code can be seen here:
https://==int_fast32_t==github. com/ samboy/ Mara DNS/ tree/ master/ deadwood- github/ update/ 3. 4. 04
As I was working on that code, I made this discovery that, on both 64-bit ARM and 64-bit x86 architectures, int32_t and int_fast32_t are the same datatype. Since there still exist some expensive mainframes out there which do not support 32-bit words (Unisys still has a mainframe which uses 36-bit words instead), C code should ideally not use int32_t, since someone may end up trying to compile the code on some exotic computer some day. Instead, one should use int_fast32_t, which is required to be supported if a compiler is C99 compliant (unlike int32_t), since this data type might be bigger than 32 bits.
I didn’t know this when I did the lion’s share of Deadwood development between 2007 and 2010; I used int32_t where most of the time int_fast32_t would had made more sense for integers which do not fit in 16 bits. The thinking when developing Deadwood is that int could be 16-bit (but is 32-bit or 64-bit on anything Deadwood compiles on), and to use exact lengths when more bits was needed in a number.
There are places where the integer must be precisely 32-bits (notably, the cryptographic random number generator), and since no one is loaning me a Unisys mainframe to develop things on something without 32-bit support, there is no way for me to meaningfully test things on a system, which has not even been confirmed to exist, which has stdint.h support but doesn’t have int32_t, uint32_t, or even int64_t.
Since I am aware of no one who has ever had an issue with this (and people have compiled Deadwood on lots of stuff like MIPS and what not), I will leave this bug, such as it is, open. If you want things to work on your Unisys mainframe, if you’re rich enough to buy a Unisys, you’re rich enough to pay me to refactor Deadwood to not need int32_t.
Comments for blog entries can be seen in the forum.