> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Dave Shield
> Sent: Thursday, August 16, 2007 2:28 AM
> In which case, Brian has identified the main issue here - the
> reliance on
> 'time_t' and related API calls to hold and manipulate
> "time-since-the-Epoch"
> values.
>
> The status here is similar to that regarding the Y2K issue.
> The Net-SNMP code predominately relies on the underlying O/S
> libraries for most of this processing. If the O/S is susceptible to
> the 2038 problem, then the Net-SNMP applications will be too.
I beg to differ. Unlike many applications, SNMP has always had the
notion of timecounter rollover and engine reboot. It should be possible to
make Net-SNMP as tolerant of the epoch as it can be using only the existing 32
bit clock. In fact, I don't see how a 64 bit clock can help the situation,
other than making 32-bit rollovers a little easier to detect.
In other words, Net-SNMP may be vulnerable if the OS' 32 bit clock is
misimplemented, but, since that should pretty much kill the whole system, it's
nothing to worry about. Other than that, you should be able to make everything
work correctly with only a 32 bit clock.
In any case, the idea that a software system will go 31 years without
an upgrade... :-}
Mike
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
