[ldns-users] Bug in ldns_year_and_yday_from_days_since_epoch (only on 32 bits)

Tom Hendrikx tom at whyscream.net
Tue Dec 27 15:28:01 UTC 2011


On 12/27/2011 01:26 AM, Tom Hendrikx wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 24-12-11 00:29, Miek Gieben wrote:
>> [ Quoting<Willem at NLnetLabs.nl>  at 00:17 on Dec 24 in "Re:
>> [ldns-users] Bug..." ]
>>> Index: util.c
>>> ===================================================================
>>>
>>>
> - --- util.c	(revision 3625)
>>> +++ util.c	(working copy) @@ -256,10 +256,7 @@ int new_year;
>>>
>>> while (days<  0 || days>= (int64_t) (is_leap_year(year) ? 366 :
>>> 365)) { -		new_year = year + (int) LDNS_DIV(days, 366); -		if
>>> (year == new_year) { -			year += days<  0 ? -1 : 1; -		} +
>>> new_year = year + (int) LDNS_DIV(days, 365); days -= (new_year -
>>> year) * 365; days -= leap_days(year, new_year); year  =
>>> new_year;
>>
>> Looks OK. I can ask Tom to apply it locally and test it a little?
>> (don't know if he's also on this list)
>>
>
> I am, but not during the holidays. Will test tomorrow ;)
>

Since Opendnssec no longer reproduces this error due to time moving on, 
I setup an nsd box with a zone where I can easily reproduce this issue:

'drill -D soa example.net @178.18.84.173' should trigger the issue on a 
32-bit box. The actual data that nsd is sending, is correct (expiration 
= 20120101224910), but drill reports expiration = 20121231224910.

After applying willems patch to ldns, drill shows the correct result. 
i'm not sure how to test this more properly, but feel free to reproduce. 
I'll leave the nsd instance running for some time.

--
Tom



More information about the ldns-users mailing list