On 15/08/07, Mike Ayers <[EMAIL PROTECTED]> wrote: > On Behalf Of Brian A. Seklecki > > > are we talking about time_t being a 64bit integer ? > > No. The year 2038 problem occurs with 32 bit integers which count > seconds > and start in 1970. SNMP uses a 32 bit timestamp, but it is referenced only > from > when the engine is booted, so v1 and v2c engines do not suffer from the year > 2038 problem, but must be rebooted at least once every 68 years. SNMPv3 > introduced a 31 bit engine boot counter which extends the potential uptime > without reboot significantly. Yes, sad to say, SNMPv3 suffers from the year > 146,135,513,385 problem. Will we ever learn?
That's the situation w.r.t the SNMP protocols, certainly. But I suspect that Nagata was asking about the status of the Net-SNMP code. 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. As soon as it becomes clear how Unix and similar O/Ss will address this problem (unsigned 32-bit or 64-bit t_time, etc), then we can check whether the Net-SNMP code needs any special attention. Dave ------------------------------------------------------------------------- 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
